!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Wolfram Webers
[email protected]
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
What is Analysis? ! Requirements Specificatio Specifications ns !
!
OOA (part 1)
Wolfram Webers
October, 2008
2
!
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
! !
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
4
$
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
A system exists in an environment ! A system can have subsystems ! A system has inputs inputs and and outputs outputs,, communicating communicati ng with the environment ! A system transforms input input to to output output ! Systems that endure have a control control mechanism ! System control relies on feedback feedback,, and feed-forward sometimes on feed-forward !
Wolfram Webers
October, 2008
5
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
System boundary
Inputs nputs
What the system does
uts Outp utpu
l o r t n o C
Feed-Forward
How the system is controlled
Feedback
System environment Source: Bennett, McRobb, Farmer (2006)
Wolfram Webers
October, 2008
6
'
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Black box We can see only the interfaces interfaces to to the system We can see, what the system needs for inputs inputs We can see, what the system has as outputs All All internals internals are hidden hidden
!
!
!
!
!
Grey box Additionally to a black box view, we can see the relations between inputs inputs and and outputs We still have no insights about the realization
!
!
!
White box We can see everything of the system It’s the developer’s view
!
!
Wolfram Webers
October, 2008
7
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
!
Information system in an organization can have different roles Operational systemswork (what the system does) automate day-to-day !
mostly transaction transaction based based
!
!
Management support systems (control) work on higher level of complexity support decision making processes
!
!
Office systems ! Real-time control systems !
Wolfram Webers
October, 2008
8
(
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Informs and enables
Drives and sets goals Business Strategy
Where IS can help
What must be done
Information System Strategy Hardware capabilities
System requirements
Information Technology Strategy
Source: Bennett, McRobb, Farmer (2006)
Wolfram Webers
October, 2008
9
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
End-user’s perspective “What system? Haven’t seen any system!” “Might work, but it’s dreadful to use.”
!
!
!
Client’s perspective
!
!
!
!
!
“If I’d known the real price,…” “It’s too late now, we needed it last April” “Now it works, but the installation…” “Everything’s changed now, we need a different system”
Developer’s perspective
!
!
!
!
“We built what they said they wanted” “There wasn’t enough time to do it better” “We said it was impossible, but no-one listened” “The system’s fine, the users are the problem”
Wolfram Webers
October, 2008
10
)
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Source: TimeKontor, Berlin, May 2001
Source: Larman – Applying UML and Patterns, p. 42
Wolfram Webers
October, 2008
11
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
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
*
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Elicitation and Analysis Sometimes called requirements elicitation or elicitation or
!
requirements discovery Involves technical staff working with customers to discover the application domain, domain, the services that the system should provide and the system’s operational constraints May involve end-users, managers, engineers involved in maintenan maintenance, ce, domain experts, trade unions, etc. These are called stakeholders
!
!
Wolfram Webers
October, 2008
14
+
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Requirements definition and specification
Requirements validation
Process entry
Domain understanding
Requirements collection
Prioritization
Conflict resolution
Classification
Wolfram Webers
October, 2008
15
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
User Requirements Statements in natural language plus diagrams of the results and qualities the user wants. Owned by the user.
!
!
System Requirements Statements, diagrams, models describing what the system must do to achieve the user requirements. Owned by the developer. developer.
!
!
Requirements Specificatio Specification n Can be seen as a contract between customer and developer.
!
Wolfram Webers
October, 2008
16
,
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Should describe functional and nonfunctional requirements so that they are understandable understanda ble by the users of the system who don’t have detailed technical knowledge ! User requirements are defined using natural language, tables and diagrams ! Make use of domain specific language specific language !
Wolfram Webers
October, 2008
17
October, 2008
18
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Order entry clerk ! Shipping and handling clerk
!
!
Salesperson Department supervisor ! Customer, who places an order !
Wolfram Webers
%
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Express, what the system must do ! Serve as a basis for designing the system ! Must have a direct relationship to the user requirement
!
They must show that the system solves the problem
!
May be used as part of the system contract ! System requirements may be expressed using system models !
Wolfram Webers
October, 2008
19
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
User Requirements
System Requirements
Description of the problem
Abstract solution
In user language
In developer language
Organized by goals
Organized by functions in a hierarchy or by objects
Subject: a type of user
Subject: the system or subsystem
Defines what the user gets
Defines what the system does
Owned by users
Owned by developers
Wolfram Webers
October, 2008
20
!"
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Non-functionall Requirements NFR) Non-functiona
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 soft qualities qualities As NFRs comprise qualities, they shall be expressed in a measurable measurable way way
!
!
!
!
Wolfram Webers
October, 2008
22
!!
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Non-functional requirements
Product requirements
Efficiency requirements
Reliability requirements
Usability requirements
Performance requirements
Organizational requirements
Portability requirements
Delivery requirements
Space requirements
External requirements
Interoperability requirements
Implementation requirements
Ethical requirements
Standards requirements
Legislative requirements
Privacy requirements
Safety requirements
Wolfram Webers
October, 2008
23
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
In principle requirements should be both complete and consistent Complete
!
They should include descriptions of all facilities required
!
Consistent
!
There should be no conflicts or contradictions in the descriptions of the system facilities
!
!
In practice, it is impossible to produce a complete and consistent requirements document Wolfram Webers
October, 2008
24
!$
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
In principle requirements should be traceable Source traceability
!
Links from requirements to stakeholders who proposed these requirements
!
Requirements traceability
!
Links between dependent requirements
!
Design traceability
!
Links from the requirements to the design
!
!
Every requirement shall be identifiable Usually some indexing/numbering is used
!
Wolfram Webers
October, 2008
25
Wolfram Webers
October, 2008
26
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Traceability matrix
D=Derived, R=Requires
!'
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
IEEE 1233:1998 for System Requirements Specifications ! Structured document
!
Introduction General system description System capabilities, conditions, and constraints System interfaces Appendices Index
!
!
!
!
!
!
!
Must be adopted to own purposes
Wolfram Webers
October, 2008
27
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
part 1
Wolfram Webers
October, 2008
28
!(
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Prototype Designer
Requirements Analyst
Project Initiation Document Elicit Requirements
Develop Prototypes
Interface Prototype
Glossary
Candidate Requirements Select Requirements
Requirements List
Evaluate Prototypes
Develop Use Cases Use Case Model
System Architect
Develop Architecture
Wolfram Webers
Initial System Architecture
October, 2008
30
!)
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
UP encourages use-case driven development 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
!
!
!
!
UP disciplines Business Modelling: business use cases (context: large scale business process re-engineering) Requirements: system use cases
!
!
Wolfram Webers
October, 2008
32
!*
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Actor
something with behaviour (person, computer system, organisation) Primary actor: actor: has user goals fulfilled through using services of the SuD (= system under discussion) Supporting actor: actor: provides a service to the SuD actor: has an interest in the behaviour of the use Offstage actor: case
!
!
! !
!
Scenario (= use case instance):
specific sequence of actions and interactions between actors and the system under discussion
!
!
Use Case: Case:
collection of related (success or failure) scenarios
!
!
UP definition of a use case:
„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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Starting Event When / in what context is the use case performed? What preconditions have to be given?
!
!
Sequence of activities
What happens upon the starting event? – List all what?), ?), but don‘t focus on the relevant activities (what details (how (how?) ?)
!
!
Situation at the end What activity and/or post-condition concludes the use case?
!
Wolfram Webers
October, 2008
34
!+
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Guideline for finding the dominant level: 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
!
!
!
Four steps: 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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
The system boundary could be software application or hardware and software a person using it or an entire organisation boundary can be clarified by defining what is outside
!
!
!
!
The system boundary for a point-of-sale point-of-sale system: 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
!,
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Reminder Questions to find actors and goals: 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?
!
!
!
!
!
!
!
!
! !
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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Identification of user goals is usually done in Identification workshops
!
Record the primary an actor-goal list actors and their goals in ! Actor-Goal list is part of the Vision artefact Actor
Goal
Cashier
process sales process rentals handle returns cash in cash out … start up shut down …
Manager
Wolfram Webers
October, 2008
38
!%
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
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: CRUD goals (Create, Retrieve, Update, Delete) are usually collapsed into one use case called „Manage <X>“
!
!
Need for communication and participation of stakeholders Wolfram Webers
October, 2008
39
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Other UML Models used as result of the analysis: diagrams forfor reflecting structural topics Class Activity diagrams reflecting processes Package diagrams for reflecting initial architectures
!
!
!
Wolfram Webers
October, 2008
40
$"
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
Analysis Patterns can help us to determine structures or behavior ! Martin Fowler (AP, 2001):
!
“Patterns are a starting point, not a destination” “Models are not right or wrong, they are more or less useful”
!
!
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
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Example: Organizational Hierachies parent
1
{hierarchy}
Organization *
University Jönköping:Organization parent
JI JIB BS S:O :Org rga a niz niza a ttio ion n
JTH: JTH:Or Org ga an n iiza zati tio on
Wolfram Webers
October, 2008
42
$!
!"#$%#"%
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Example: Extending patterns {a compnany is the parent of divisions, which is the parent of departments}
parent
1
{hierarchy}
Organization *
Company
Division
Department
Wolfram Webers
October, 2008
43
ÖNKÖPING INTERNATIONAL BUSINESS SCHOOL JÖ NK ÖP IN G UN IV ER SI TY
!
Example: Party (abstraction of people and organization) parent
1
{hierarchy} Party
Party *
parent 1 Person
Organization
Person
{hierarchy}
Organization *
Wolfram Webers
October, 2008
44
$$