!

"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Wolfram Webers wewo@ihh.hj.se

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

What is Analysis? !! Requirements Specifications !! OOA (part 1)

!!

Wolfram Webers

October, 2008

!&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!! !!

We need to understand the problems first In information system development:

!! !! !! !! What is the system? Who uses the system? What is the purpose of the system? Where is the border of the system?

!!

From the business perspective:

!! How do we establish the business requirements for a new system? !! What effects will the new system have on the organization? !! How do we ensure that the system we build meet its requirements?

Wolfram Webers

October, 2008

$&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

A system exists in an environment !! A system can have subsystems !! A system has inputs and outputs, communicating with the environment !! A system transforms input to output !! Systems that endure have a control mechanism !! System control relies on feedback, and sometimes on feed-forward
!!

Wolfram Webers

October, 2008

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

System boundary

Inputs

What the system does

Control

Outputs

Feed-Forward

How the system is controlled

Feedback

System environment

Source: Bennett, McRobb, Farmer (2006)

Wolfram Webers

October, 2008

'&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Black box

!!

Grey box

!! We can see only the interfaces to the system !! We can see, what the system needs for inputs !! We can see, what the system has as outputs !! All internals are hidden !! Additionally to a black box view, we can see the relations between inputs and outputs !! We still have no insights about the realization !! We can see everything of the system !! Its the developers view
Wolfram Webers October, 2008 7

!!

White box

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Information system in an organization can have different roles !! Operational systems (what the system does)
!!

!!

Management support systems (control)

!! work on higher level of complexity !! support decision making processes

!! automate day-to-day work !! mostly transaction based

Office systems !! Real-time control systems

!!

Wolfram Webers

October, 2008

(&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Informs and enables Business Strategy Where IS can help

Drives and sets goals

What must be done

Information System Strategy Hardware capabilities System requirements

Information Technology Strategy

Source: Bennett, McRobb, Farmer (2006)

Wolfram Webers

October, 2008

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

End-users perspective Clients perspective

!! !! !! !! !! !! !! !!

!! What system? Havent seen any system! !! Might work, but its dreadful to use. If Id known the real price, Its too late now, we needed it last April Now it works, but the installation Everythings changed now, we need a different system We built what they said they wanted There wasnt enough time to do it better We said it was impossible, but no-one listened The systems fine, the users are the problem
Wolfram Webers October, 2008 10

!!

!!

Developers perspective

)&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Source: TimeKontor, Berlin, May 2001

Source: Larman Applying UML and Patterns, p. 42

Wolfram Webers

October, 2008

11

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Analysis is a collection of actions aiming to ensure that the envisioned system meets the goals !! Analysis is part of a development process !! We can define a process as an orchestration of actions/tasks with specific purposes and outcomes !! Methods will guide how to fulfill those tasks !! Methods can rely on the usage of specific tools and paradigms
!!
Wolfram Webers October, 2008 12

*&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Elicitation and Analysis

!! Sometimes called requirements elicitation or requirements discovery !! Involves technical staff working with customers to discover the application domain, the services that the system should provide and the systems operational constraints !! May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

Wolfram Webers

October, 2008

14

+&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Requirements validation Domain understanding

Requirements definition and specification

Prioritization

Process entry

Requirements collection

Conflict resolution

Classification

Wolfram Webers

October, 2008

15

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

User Requirements

!!

System Requirements

!! Statements in natural language plus diagrams of the results and qualities the user wants. Owned by the user. !! Statements, diagrams, models describing what the system must do to achieve the user requirements. Owned by the developer. !! Can be seen as a contract between customer and developer.
Wolfram Webers October, 2008 16

!!

Requirements Specification

,&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Should describe functional and nonfunctional requirements so that they are understandable by the users of the system who dont have detailed technical knowledge !! User requirements are defined using natural language, tables and diagrams !! Make use of domain specific language
!!

Wolfram Webers

October, 2008

17

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Order entry clerk !! Shipping and handling clerk !! Salesperson !! Department supervisor !! Customer, who places an order
!!

Wolfram Webers

October, 2008

18

%&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Express, what the system must do !! Serve as a basis for designing the system !! Must have a direct relationship to the user requirement
!! !!

May be used as part of the system contract !! System requirements may be expressed using system models

!! They must show that the system solves the problem

Wolfram Webers

October, 2008

19

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

User Requirements Description of the problem In user language Organized by goals Subject: a type of user Defines what the user gets Owned by users

System Requirements Abstract solution In developer language Organized by functions in a hierarchy or by objects Subject: the system or subsystem Defines what the system does Owned by developers

Wolfram Webers

October, 2008

20

!"&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Functional requirements

!! Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. !! Depend on the type of software, expected users and the type of system where the software is used !! Functional user requirements may be high-level statements of what the system should do, but only functional system requirements should describe the system services in detail

Wolfram Webers

October, 2008

21

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Non-functional Requirements (NFR)

!! Statements about the quality of the services the system should provide or qualities of the system itself. !! NFRs are highly depend on the domain in which the system is to be used !! NFRs are not limited to soft qualities !! As NFRs comprise qualities, they shall be expressed in a measurable way

Wolfram Webers

October, 2008

22

!!&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Non-functional requirements

Product requirements

Organizational requirements

External requirements

Efficiency requirements

Reliability requirements

Portability requirements

Interoperability requirements

Ethical requirements

Usability requirements

Delivery requirements

Implementation requirements

Standards requirements

Legislative requirements

Performance requirements

Space requirements

Privacy requirements

Safety requirements

Wolfram Webers

October, 2008

23

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

In principle requirements should be both complete and consistent

!! Complete
!! They should include descriptions of all facilities required !! There should be no conflicts or contradictions in the descriptions of the system facilities

!! Consistent

!!

In practice, it is impossible to produce a complete and consistent requirements document

Wolfram Webers

October, 2008

24

!$&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

In principle requirements should be traceable

!! Source traceability
!! Links from requirements to stakeholders who proposed these requirements !! Links between dependent requirements !! Links from the requirements to the design

!! Requirements traceability !! Design traceability

!!

Every requirement shall be identifiable

!! Usually some indexing/numbering is used

Wolfram Webers

October, 2008

25

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Traceability matrix

D=Derived, R=Requires

Wolfram Webers

October, 2008

26

!'&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

IEEE 1233:1998 for System Requirements Specifications !! Structured document

!!

!!

Must be adopted to own purposes

!! Introduction !! General system description !! System capabilities, conditions, and constraints !! System interfaces !! Appendices !! Index

Wolfram Webers

October, 2008

27

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

part 1

Wolfram Webers

October, 2008

28

!(&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Requirements Team

Use Case Model

Requirements List

Project Initiation Document

Requirements capture and modeling

Interface Prototype

Initial System Architecture

Glossary

Wolfram Webers

October, 2008

29

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Requirements Analyst

Prototype Designer

Project Initiation Document

Elicit Requirements

Develop Prototypes Glossary

Interface Prototype

Candidate Requirements Select Requirements

Requirements List

Evaluate Prototypes

Develop Use Cases Use Case Model

System Architect

Develop Architecture

Initial System Architecture

Wolfram Webers

October, 2008

30

!)&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Use Cases are stories of using a software system to meet goals

!! Mechanism to capture user needs and system requirements !! Simplicity and utility are key success factors: stakeholders have to be able to contribute to definition and evaluation of requirements !! Use cases represent primarily functional requirements

!! !!

Use Cases are primarily text documents, not diagrams UML defines a use case diagrams to illustrate names of the use cases and actors, and their relationship
Wolfram Webers October, 2008

31

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

UP encourages use-case driven development

!!

UP disciplines

!! Requirements are primarily recorded in use cases (Use-Case Model) !! Use cases are an important part of iterative planning (chose use case scenarios or entire use cases for an iteration) !! Use case realization drives the design !! Use cases influence the organisation of user manual !! Business Modelling: business use cases (context: large scale business process re-engineering) !! Requirements: system use cases

Wolfram Webers

October, 2008

32

!*&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Actor

!!

Scenario (= use case instance): Use Case:

!! something with behaviour (person, computer system, organisation) !! Primary actor: has user goals fulfilled through using services of the SuD (= system under discussion) !! Supporting actor: provides a service to the SuD !! Offstage actor: has an interest in the behaviour of the use case !! specific sequence of actions and interactions between actors and the system under discussion !! collection of related (success or failure) scenarios !! A set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.
Wolfram Webers October, 2008 33

!! !!

UP definition of a use case:

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Starting Event

!!

Sequence of activities

!! When / in what context is the use case performed? What preconditions have to be given? !! What happens upon the starting event? List all relevant activities (what?), but dont focus on the details (how?) !! What activity and/or post-condition concludes the use case?

!!

Situation at the end

Wolfram Webers

October, 2008

34

!+&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Guideline for finding the dominant level:

!!

Four steps:

!! Focus on use cases on the level of Elementary Business Processes (EBP): !! EBP is a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state !! Choose the system boundary !! Identify the primary actors !! For each identify their user goals !! Define use cases that satisfy the user goals
Wolfram Webers October, 2008 35

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

The system boundary could be

!!

The system boundary for a point-of-sale system:

!! software application or hardware and software !! a person using it or an entire organisation !! boundary can be clarified by defining what is outside

!! The point-of-sale system itself !! Everything outside of the system is outside the system boundary

!! The cashier, payment authorization service, and so on

Wolfram Webers

October, 2008

36

!,&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Reminder Questions to find actors and goals:

!! !!

Focus is on Primary Actors, not on Supporting Actors Be suspicious if no primary actors are external to the system
Wolfram Webers October, 2008 37

!! Who starts and stops the systems? !! Who does user- and security-management? !! Is there a monitoring process that restarts the system if it fails? !! How are software updates handled? Push or pull update? !! Who does system-administration? !! Is time an actor because the system does something in! response to a time event? !! Who evaluates system activity and performance? !! Who evaluates logs? Are they remotely retrieved?

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Identification of user goals is usually done in workshops !! Record the primary actors and their goals in an actor-goal list !! Actor-Goal list is part of the Vision artefact
!!
Actor Cashier Goal process sales process rentals handle returns cash in cash out start up shut down
Wolfram Webers October, 2008 38

Manager

!%&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Define one EBP use case for each user goal

!! Name the use case similar to the user goal !! Name the use case starting with a verb !! Keep the user interface out and focus on actor intent

!!

Common exception:

!!

Need for communication and participation of stakeholders

Wolfram Webers October, 2008 39

!! CRUD goals (Create, Retrieve, Update, Delete) are usually collapsed into one use case called Manage <X>

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Other UML Models used as result of the analysis:

!! Class diagrams for reflecting structural topics !! Activity diagrams for reflecting processes !! Package diagrams for reflecting initial architectures

Wolfram Webers

October, 2008

40

$"&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Analysis Patterns can help us to determine structures or behavior !! Martin Fowler (AP, 2001):
!!

Analysis Pattern are observed structures and/ or behaviors of previous work done !! Patterns are highly abstracted and need to be adopted
!!
Wolfram Webers October, 2008 41

!! Patterns are a starting point, not a destination !! Models are not right or wrong, they are more or less useful

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Example: Organizational Hierachies

parent 1 {hierarchy} * Organization

University Jnkping:Organization parent

JIBS:Organization

JTH:Organization

Wolfram Webers

October, 2008

42

$!&

!"#$%#"%&

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Example: Extending patterns

{a compnany is the parent of divisions, which is the parent of departments}

parent

{hierarchy} *

Organization

Company

Division

Department

Wolfram Webers

October, 2008

43

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

!!

Example: Party (abstraction of people and organization)

parent 1 {hierarchy} Party * parent 1 Person Organization Person Organization * {hierarchy} Party

Wolfram Webers

October, 2008

44

$$&