Wolfram Webers Wewo@ihh - Hj.se: What Is Analysis? Requirements Specifications OOA (Part 1)

!
"#$%#"%&
JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY
Wolfram Webers wewo@ihh.hj.se

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

!!
Wolfram Webers
October, 2008
!&
!"#$%#"%&

JNKPING UNIVERSITY

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 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 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 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 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 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 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
!!
!!
Developers perspective
)&
!"#$%#"%&

JNKPING UNIVERSITY
Source: TimeKontor, Berlin, May 2001
Source: Larman Applying UML and Patterns, p. 42
Wolfram Webers
October, 2008
11

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
!!
*&
!"#$%#"%&

JNKPING UNIVERSITY

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 UNIVERSITY
Requirements validation Domain understanding
Requirements definition and specification
Prioritization
Process entry
Requirements collection
Conflict resolution
Classification
Wolfram Webers
October, 2008
15

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.
!!
Requirements Specification
,&
!"#$%#"%&

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 UNIVERSITY
Order entry clerk !! Shipping and handling clerk !! Salesperson !! Department supervisor !! Customer, who places an order
!!
Wolfram Webers
October, 2008
18
%&
!"#$%#"%&

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 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 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 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 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 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 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 UNIVERSITY
!!
Traceability matrix
D=Derived, R=Requires
Wolfram Webers
October, 2008
26
!'&
!"#$%#"%&

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 UNIVERSITY
part 1
Wolfram Webers
October, 2008
28
!(&
!"#$%#"%&

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 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 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 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 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.
!! !!
UP definition of a use case:

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 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

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 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
!! 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 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
Manager
!%&
!"#$%#"%&

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

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

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 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
!!
!! Patterns are a starting point, not a destination !! Models are not right or wrong, they are more or less useful

JNKPING UNIVERSITY
!!
Example: Organizational Hierachies

parent 1 {hierarchy} * Organization
University Jnkping:Organization parent
JIBS:Organization
JTH:Organization
Wolfram Webers
October, 2008
42
$!&
!"#$%#"%&

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 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
$$&

Wolfram Webers Wewo@ihh - Hj.se: What Is Analysis? Requirements Specifications OOA (Part 1)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wolfram Webers Wewo@ihh - Hj.se: What Is Analysis? Requirements Specifications OOA (Part 1)

Uploaded by

Copyright:

Available Formats

!

JNKPING INTERNATIONAL BUSINESS SCHOOL