Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
© Fraunhofer IESE
REQUIREMENTS ENGINEERINGLECTURE 2016/2017
Dr. Joerg Doerr
Information Systems RE
© Fraunhofer IESE
2
AGENDA
Basics
Context Analysis
Business Process & Data Modeling
BPMN
EPC
UML
Use Case Analysis
Specific Challenges & Aspects
© Fraunhofer IESE
3
BASICSInformation Systems RE
© Fraunhofer IESE
4
What is an Information System?
An information system is a collection of hardware, software, data, people and procedures that work together to produce quality information.
An information system commonly refers to a basic computer system but may also describe a telephone switching or environmental controlling system. Information systems involves resources for shared or processed information, as well as the people who manage the system. People are considered part of the system because without them, systems would not operate correctly.
Information systems are used to integrate and streamline business processes across organizational and geographical borders and to (partially) automate the input, storage, transmission, and transformation of business data.
© Fraunhofer IESE
5
How would you Elaborate the Requirements for an Information System?
© Fraunhofer IESE
6
Generic RE Process according to Core Activities
Elicitation DocumentationVerification &
Alignment
Management
© Fraunhofer IESE
7
Typical Questions in Practice when Merely Adhering to the Core Activities
What do I have to elicit and describe?
In which order?
What is the right degree of detail?
How do I know when I‘m done?
Who can contribute which information?
Where do I have to write certain information down?
© Fraunhofer IESE
8
Reference Objects for Requirements
Requirement
Stakeholder
Reference Object
has
concerns
Reference objects defines topics for which stakeholders have to make decisions regarding the design of a system ( decision points).
Reference objects defines topics for which stakeholders have to make decisions regarding the design of a system ( decision points).
Decision Point
addresses
© Fraunhofer IESE
9
Reference Objects & Decision Points…
support completeness
Decisions have always to be done in a project, either implicitly or explicitly. By keeping concrete reference objects in mind, corresponding decisions can be done explicitly and, thus, by stakeholder agreement rather than developers’ decisions.
support focusing & responsibility assignment
It is neither meaningful nor possible to discuss about all reference objects with all stakeholders at one point in time. Thus, by covering different decision points / reference objects in different meetings, discussions can be done in a more targeted way.
clarify level of detail
The reference objects clarify the degree of detail for corresponding requirements and hinder stakeholders from addressing too fine-grained issues.
© Fraunhofer IESE
10
Frameworks for Information System Development (1)
Purpose
Define and logically distinguish the reference objects and decision points that should be addressed and modelled when designing an (business) information system
Main Content
Responsible roles (WHO)
Supported tasks / functions / activities (WHAT)
Developed products / achieved goals (WHY)
Processed data and information (WITH WHAT)
Conducted processes / applied rules (HOW)
Triggers / events (WHEN)
© Fraunhofer IESE
11
Frameworks for Information System Development (2)
Examples
ARIS House (by A.-W. Scheer)
Zachman Framework (by J. Zachman)
TORE Framework (by B. Paech, K. Kohler, continuously enhanced by Fraunhofer IESE)
1. Scheer, A.-W.: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. 4. Auflage. Springer, 2001
2. Zachman, J. A.: A framework for information systems architecture. In: IBM Systems Journal. 26, Nr. 3, 1987
© Fraunhofer IESE
12
ARIS House (1)
WHO
WHAT
WHY
WITH WHAT
HOW
© Fraunhofer IESE
13
ARIS House (2)
IT Concept
Business Concept
Implementation
Business Concept
IT Concept
Implementation
Business Concept
IT Concept
Implementation
Business Concept
IT Concept
Implementation
Business Concept = Requirements
© Fraunhofer IESE
14
Zachman Framework
Copyright © 2013 Cambridge Technical Communicators
© Fraunhofer IESE
15
The TORE Decision Framework (Version 2013 for BIS)
StakeholdersProject Level
Business Level
InteractionLevel
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
Business Data & Rules
System FunctionsInteractionsInteraction Data
& RulesLogical UI Structure
System Level
Requirements-relevant decisions for BIS
Internal Functions Internal DataSystem ArchitectureApplication Core
GUI LayoutSpecific GUI
FunctionsDialogs GUI DataGUI
Project GoalsAddressed
Tasks & ProcessesProject Topic
© Fraunhofer IESE
16
Task-oriented Requirements Engineering (TORE)
Idea:
System development should be driven from the goals to be achieved and tasks to be supported
Each system property can be motivated via step-wise refinement
not more or less than necessary
Assures a constructive achievement of (business) goals
Enables traceability as well as better communication between business and IT departments
Task-oriented Requirements Engineering (TORE) takes the stakeholders and their tasks & processes as the starting point for the requirements development.
Task-oriented Requirements Engineering (TORE) takes the stakeholders and their tasks & processes as the starting point for the requirements development.
© Fraunhofer IESE
17
Decision Points at the Project Level
What is the overall topic of the project?
Who are the stakeholders (e.g., departments, role, persons, etc.) that are affected by this topic?
Which goals is the project supposed to achieve? What should be the benefit at the end?
Which business processes and tasks are to be analyzed and addressed in the context of the project?
© Fraunhofer IESE
18
Decision Points at the Business Level
How are the business processes and tasks currently performed? What are their strengths and weaknesses?
How should the business processes and tasks be performed in the future in order to be able to achieve the project goals?
Which parts / steps of the to-be business processes and tasks should be supported or even automated by the system to be developed?
Which data and rules are relevant in the considered business processes and tasks?
© Fraunhofer IESE
19
Decision Points at the Interaction Level
How should users or external systems interact with the system to be developed for achieving the results of certain steps in the business processes?
Which system functions are needed for realizing the system responsibilities or interactions?
Which data are exchanged in these interactions?
How should data and system functions be grouped logically within the user interface? How should data be grouped within a document?
© Fraunhofer IESE
20
Simplified RE Process for Information Systems
The decision points do not prescribe a concrete RE process, but a simplified sequence of requirements development steps for information systems.
Stakeholder Project GoalsAddressed
Tasks & ProcessesProject Topic
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
Business Data & Rules
System Functions
InteractionsInteraction Data
& Rules
Logical GUI Structure
© Fraunhofer IESE
21
Interweaving with RE Core Activities
Elicitation and documentation is done “en bloc” for each decision point, e.g.,
Verification & Alignment is done at certain quality gates, e.g.,
Management is done continuously in parallel
Elicitation of To-be (Process)
Situation
Documentation of To-be (Process) Situation
Elicitation of System
Responsibilities
Documentation of System
Responsibilities
Documentation of As-is
(Process) Situation
Verification & Alignment of As-is (Process)
Situation
Elicitation of To-be (Process)
Situation
© Fraunhofer IESE
22
Strategies for Conducting Requirements Development
Sequential (Waterfall)
Parallel
Incremental
© Fraunhofer IESE
24
Sequential Requirements Development
AddressedTasks & Processes
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
System Functions
Complete requirements document at the end of the process.Easy to perform.
The larger the project, the later development can start.Inflexible changes.
© Fraunhofer IESE
25
Parallel Requirements Development
AddressedTasks & Processes
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
System Functions
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
Complete requirements document at the end of the process.Easy to perform. Fast(er).
Consolidation might be difficult. Finalization depends on the slowest branch. Inflexible changes.
© Fraunhofer IESE
26
Incremental Requirements Development
AddressedTasks & Processes
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
System Functions
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
System Functions
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
System Functions
Development can already start before requirements are complete.Stakeholders’ feedback on early implementations can be considered in subsequent increments.
Only partial requirements documents. Dependencies between increments must be considered. Crucial requirements must be addressed in the first increments.
© Fraunhofer IESE
27
Logical Phases in Information Systems RE (1)
Stakeholder Project GoalsAddressed
Tasks & ProcessesProject Topic
As-is (Process) Situation
To-be (Process) Situation
System Responsibilities
Business Data & Rules
System Functions
InteractionsInteraction Data
& Rules
Logical GUI Structure
Step 1: Context Analysis
Step 2: Business Process & Data Analysis
Step 3: Use Case Analysis