Development of Business

IS203 Section A.
2 - Requirements Engineering and IS Development

Dr. Norbert Koppenhagen
Chair of Information Systems IV, Business School,
Institute for Enterprise Systems (InES), University of Mannheim
SAP SE

Mannheim, September 10th 2014
13 10
Course Structure 4 Blocks
1. Introduction and Fundamentals of IS
2. Requirements Engineering and IS Development
3. Exercise Young IT Consultant
3 2 1 6 5 4 9 8 7 12 11 14
1. IS Project Management w/ Guest Talk
2. IS Implementation
3. Exercise Senior Manager
1. IS Delivery
2. IS Management
3. Exercise w/ Guest Talk, Experiment (9 & 10)
1. IS Use
2. IS Business Value
3. Exercise CIO
Block
A
Block
B
Block C
Block D
Exam
prep.
2
HWS 2014 - IS203 DeMIS, Section A.2
Goals of todays session
You can identify, classify, and
structure requirements
You are able to gather
requirements from the future users
and stakeholders involved
Understand differences between
software development models

3
Todays session
4
Agenda
1 Introduction and Motivation
2 Definition of Software Requirements
3 Gathering Software Requirements
4 Managing Software Requirements
5 Software Development Approaches
6 Summary
Development processes in the software industry
5
IS

Technology is the focus of this section of the lecture
Especially application system aka software artifact

Social Sub-System Technological Sub-System
Cannot be developed
New artifacts can be developed
(the design of alternative worlds)
Often refer to structures from
outside the working place (e.g.,
habits, culture)
Require dedicated change effort
(often gradual and over time)
Two types of software artifacts
Product Software Tailor-Made
Standard software Custom software
Generally purchased from vendor
Service contract (Werkvertrag)
Made to order or in-house
purchase of things (Sachkauf)
Characteristics
Shared development costs
Best-practices established
Dev and maintenance by supplier
Preview possible
Documentation and education
material available
Reference implementation available
Characteristics
Tailored solution, focus on
required functionalities only
Competitive advantage
Company-specific changes
possible
Independency of software supplier
Terminology of company used,
less education effort
Source: adapted from Xu and Brinkkemper (2007)
6
Tailored software project: dm point-of-sale software

Business challenge:
Increasing centralization of
trading companies
Increasing international branches
Application solution:
Tailored software replaced standard software
Easy-to-use touch screen
Why did it work / characteristics:
Simple complexity
Flexibility more important than standard
Benefits:
Tailored software
Centralized maintenance
Source: Lambertz (2010)
November 2006 First contact
January 2007 First prototype
Spring 2007 Contract
June 2007 Start of implementing POS and servers in branches
Fall 2007 Start of implementing central servers
January 2008 Start of implementing coupon server
August 2008 First productive branch
January 2009 First 10 branches productive
March 2009 First 100 branches productive
April 2009 First business-day roll-outs
May-July 2009
Main roll-out for more than 1,000 branches in
Germany
July 2009 Project piloting in Austria
December 2009 Project complete
7
Todays session
8
Agenda
6 Summary
Why requirements engineering matters
The study of Hofmann and Lehner (2001) analyzed several
IT implementation projects with respect to
Knowledge
Resources
Top performers
Performed RE throughout the project
Invested twice the average effort to specify requirements
Had a stable core team, which was supported
by shared domain experts
Source: Hofmann and Lehner (2001)
Process
Performance
Fixing a requirements errors
after delivery may cost up to
200 times the cost of fixing an
implementation error
Source: Davis (1993)
9
What is a requirement?
Requirements should state what the system should do
Design should describe how the system does this
The systems architecture is designed to support the
requirements
A requirement is:
(1) a condition or capability needed by a user to solve a problem or
achieve an objective
(2) a condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or
other formally imposed document
(3) a documented representation of a condition or capability as in (1) or
(2)
Source: IEEE Std. 830-1998
10
Statements in natural language
Supported by diagrams of the services the system provides
and its operational constraints
Written for customers
User
Requirements
Structured document setting out detailed descriptions
of the systems functions, services and operational
constraints
Defines what should be implemented
Can be part of contract between client and contractor
System
Requirements
Types of requirements
11
Types of requirements
Functional requirements Example
Define the provided services
Describe the system functionalities
Describe the system behavior
Describe the system reactions
An bank online account must show
the withdrawal transactions (date,
time, location, amount) for the
user-chosen period (e.g., 1, 3 or 6
months).
Non-functional requirements Example
Specification of quality of services
Constraints on the services (e.g., timing
constrains, fault tolerance, exception handling)
When an account is queried, the
response time must be below 2
seconds.
12
Details and metrics for non-functional requirements
A non-functional requirement may generate a number of related functional requirements
Example: Security constraints generate functional requirements that restrict the access to functionality based
on roles
Non-functional requirements carry risks because they can affect the overall architecture
in a non-intuitive way
Example: To ensure performance, you may have to organize the system to minimize communications
between components
Property Measure
Speed
Processed transactions/second
User/event response time
Size
Mbytes
Number of ROM chips
Ease of use
Training time
Number of help frames
Reliability
Probability of unavailability
Rate of failure occurrence
Robustness
Time to restart after failure
Probability of data corruption on failure
Portability
Percentage of target dependent statements
Number of target systems
13
Prioritization of requirements
Definitions
Examples
Examples are contractual obligations, legal
requirements or fundamental business
functions
Mandatory Requirements
Fulfilling a business need
Not implementing results in a loss of
customer and revenue
Drastic impact on business value
Mandatory Requirements
Examples are additional functions that are
useful, but not needed during the main
business process.
Optional Requirements
Less degree of urgency
Implementing may result in
additional business benefits
Can turn into a mandatory one
Optional Requirements
14
How to precisely describe a software requirement?
Precision
Ambiguous requirements may be interpreted in different ways by developers and users (e.g. via
systematic manual analysis and regular reviews)
Completeness
They should include the full set of requirements (e.g., what is the full set of information required?)
Consistence
There should be no conflicts or contradictions in the descriptions of the system facilities (e.g. left-right
issue)
In principle,
requirements should be both
complete and consistent
In practice,
it seems impossible to produce a complete and
consistent requirements document
Req-136: The financial calculation system should provide a right-hand sidebar (RS) with
information about further functions in different languages. The RS is always displayed on
the bottom left corner of the current page.
What kind of
information?
System or math-
functions?
Which
languages?
Left or right?

Source: Sommerville (2010), Alavi (1984)
15
Todays session
16
Agenda
6 Summary
Requirements Determination and Management
We will use a somewhat simplified summary of this approach
Requirements
Determination
Requirements
Management
Elicitation Validation
Analysis
and
Specification
Change
Implementation
Traceability
17
Requirements Elicitation
Discovers all facets of
requirements
Involves all the relevant
stakeholders of the
project
Requirements Specification
Classifies and organizes
requirements
Prioritizes and negotiates
Covers functional and
technical analysis
Requirements
Management
Documents the history of
accepting new requirements
Changes or drops existing requirements
Traces requirements
implementation
Requirements Validation
Checks if the requirements
actually define the system
customers really want
Requirements management tasks
18
requirements
stakeholders of the
project
requirements
technical analysis
Requirements
Management
Traces requirements
implementation
19
Elicitation allows the development team to dig for the customers
requirements underlying the solution to be developed
Successful projects reflect requirements that are derived from
data from a variety of sources
Elicitation provides grounds to systematically organize,
synthesize, and rationalize the data
Rationalizing helps to reduce the number of requirements that
may be in conflict or redundant
Elicitation is the process of drawing out a response from someone
(e.g., a customer), either through questioning or observing
20
Problems of elicitation
Technical staff working with
customers
Stakeholders (end-users,
managers, maintenance
engineers, domain experts)
Stakeholders often dont know what they really want
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting requirements
Organizational and political factors influence requirements
The requirements change during the analysis process
New stakeholders emerge
The business environment may change
Requirements
elicitation /
discovery
Development team Project sponsors
21
Which type of elicitation fits which
objectives?
Elicitation Techniques
(suitable for)
Express
wishes
Identify
possibilities
Impose real
condition
Identify market
potential
Interviews + - + o
Use-cases o - + o
Scenarios + o o -
Personas o + - o
Ethnography o o + o
Survey, questionnaire o - + +
Further details will be discussed and practically learned
in the exercise session
22
Be careful when talking to external
sources
One essential tool needed for opening
dialogues about future plans with external
sources is a non-disclosure agreement (NDA)
The NDA legally binds third parties to hold
information in confidence and not use it in a
way that represents a competitive threat to the
company
Some companies include NDA clauses in their
sales contracts between customers and
partners
NDA language is even present in most
employment contracts
23
Design Thinking Approach
24
Source: HPI 2014 - http://www.hpi.uni-potsdam.de/d_school/designthinking/core_elements.html?L=1
requirements
stakeholders of the
project
requirements
technical analysis
Requirements
Management
Traces requirements
implementation
25
Requirements classification and organisation
Groups related requirements and organises them into coherent clusters

Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts

Requirements specification
Requirements are documented and input into the next round of the spiral

The requirements may be part of a contract for the system
development and may be captured in a requirements
document

Result is NOT a design document. It should set of WHAT
the system should, do rather than HOW it should do it

26
Writing a requirements document
Requirements document
Explains why a product is needed
Puts the product in context
Describes what the finished product will be like

It should contain
Introduction to document
Description of product and functionality
Listed requirements
Appendices, glossary, references, index

Important input to validate requirements

Guides development and testing
Source: Smith (2011)
27
The requirements document
Official statement of what the
development team needs to
implement
Especially important in case an
external contractor is hired
Wide set of users and
stakeholders
If agile methods are being
used, might grow with the
project or be done for each
iterative step

Source: Sommerville (2010)
(1) Preface
(2) Introduction
(3) Glossary
(4) User requirements
specification
(5) System
architecture
(6) System
requirements
specification
(7) System models
(8) System evolution
(9) Appendices
(10) Index
28
To extend natural language consider
these
Structured specifications
Limits the freedom of the requirements writer
Requirements are written in a standard way
Might be too rigid for some requirements (e.g., business-oriented)
Form-based
Standardized forms are used to document each requirement
Different layouts support the different requirement types
Facilitates the requirements management process
Tabular
Used to refine or supplement natural language
Useful when defining possible alternative courses of action
Allows for quick overview over often lengthy descriptions

29
Users of a requirements document
System
customers
Specify the requirements and read them to check that they meet their
needs. Customers specify changes to the requirements.
Managers
Use the requirements document to plan a bid for the system and to plan the
system development process.
System
engineers
Use the requirements to understand what system is to be developed.
System test
engineers
Use the requirements to develop validation tests for the system.
System
maintenance
engineers
Use the requirements to understand the system and the relationships
between its parts.
30
Problems with natural language
Lack of clarity
Requirements
confusion
Requirements
amalgamation
31
Ways of writing requirements
specifications
Notation Description
Natural language
The requirements are written using numbered sentences in natural language. Each sentence
should express one requirement.
Structured natural
language
The requirements are written in natural language on a standard form or template. Each field
provides information about an aspect of the requirement.
Design description
languages
This approach uses a language like a programming language, but with more abstract
features to specify the requirements by defining an operational model of the system. This
approach is now rarely used although it can be useful for interface specifications.
Graphical notations
Graphical models, supplemented by text annotations, are used to define the functional
requirements for the system; UML use case and sequence diagrams are commonly used.
Mathematical
specifications
These notations are based on mathematical concepts such as finite-state machines or sets.
Although these unambiguous specifications can reduce the ambiguity in a requirements
document, most customers dont understand a formal specification. They cannot check that it
represents what they want and are reluctant to accept it as a system contract.
Source: Sommerville (2010)
32
requirements
stakeholders of the
project
requirements
technical analysis
Requirements
Management
Changes or drops existing
requirements
Traces requirements
implementation
33
Requirements validation
Requirement reviews Rapid Prototyping
Development of an early,
rudimentary version of
system
Includes essential features
Assists when requirements
are poorly understood
Enable stakeholders to get
experience
Promotes discussion of
unidentified features
Common point of reference

Start early with developing test
cases
Having test cases already in the
requirement specification can
help to prevent future problems
Test conditions and expected
results need to be specified
Expected results can help to
validate the understanding of a
requirement
Systematic manual analysis
Regular reviews during
requirements definition
Both client and contractor
staff should be involved
Reviews may be formal (with
completed documents) or
informal
Communication between
developers, customers, and
users can avoid problems
early
Source: Sommerville (2010), Alavi (1984)
Early Test Case Development
34
Todays session
35
Agenda
6 Summary
requirements
stakeholders of the
project
requirements
technical analysis
Requirements
Management
Changes or drops existing
requirements
Traces requirements implementation
36
Requirements management
Requirements management is the process of identifying, eliciting,
documenting, analyzing, tracing, prioritizing, validating, and
agreeing on requirements and then controlling implementation and
change as well as communication with relevant stakeholders
Source: based on Ruhe (2005)
Requirements
identification
Establishing
requirements repository
Change management
process and policies
Traceability
policies
37
Customer RM
Ensures that customer requirements
are recognized and implemented in
products.
Product RM
Ensures sustainability and profitability
of development by defining, prioritizing,
and mapping product requirements
from diverse sources.
Project RM
Analyzes and details product
requirements and ensures
implementation within the project
boundaries
customers have requirements
in order to get solutions to
their problems
3 perspectives on managing
requirements
Customer
orientation
products provide solutions to
these customer problems and
the corresponding
requirements
Product
orientation
New software is developed
in projects with well-defined
contents and schedules
addressing product
requirements
Project
orientation
38
Managing Requirements: Traceability
Traceability
the source of each requirement is identified and linked back to the original
customer requirement that was elicited

Testable
defines that within one requirement there are no contradicting aspects, which
makes the requirement per se not testable

Tracking in requirements databases:

In Practice, it often is important to know the source of the
requirement and to ensure that it was tested.
Req-ID Priority Description (short) Description (long) Origin Effort
147 High Need of a The system should DE-17
39
Tool support for managing requirements
Formal requirements tracking software tools can help to gather, track,
and manage requirements
Help collect input, organize it, and maintain the source and other
information for future use
Some systems can automatically generate requirements documents
Some systems provide ongoing communication about development
progress back to the sources of the requirements

The Accept360-Suite consists of:
Accept Ideas
Accept Portfolio
Accept Requirements
Accept Agile

For more see: http://www.volere.co.uk/tools.htm
40
Changing requirements
Business and technical environment of the system often
change after installation
Introduction of new hardware
Necessary to interface the system with other systems
Business priorities change (with consequent changes in the
system support required)
New legislation and regulations may be introduced that the
system must necessarily abide by
The people who pay for a system and the users of that
system are rarely the same people
System customers impose requirements because of
organizational and budgetary constraints
These may conflict with end-user requirements
After delivery, new features may have to be added for users if
the system is to meet its goals

41
Todays session
42
Agenda
6 Summary
Evolution of Software Development
NATO conference in
Garmisch
(1
st
SE conference
1968)
Software
crisis
The term
software
engineering
(SE) appears
Development of advanced
techniques (object-
orientation, spiral model
for risk management)
Further advances
in SE (object-
modeling, design
patterns)
New development trends
(e.g., XP, Design Thinking,
SOA)
43
Structured and agile development models
Most development models can be associated with
any one of the two major schools of thought

No right or wrong software processes
Most projects include notions of both plan-driven and incremental
Match characteristics to the development project at hand

Structured Agile
Plan-driven Requirements-driven
Sequential stages Iterative cycles
Pre-planned Incremental
Completing goals Approximating requirements
One overall final product Series of intermediary releases
4
4
44
Structured models: Waterfall

Phased approach in a sequential fashion
Analysis: Study, understand, and specify the system requirements
Design: Study, understand and design the system architecture
Implementation: Create individual code units and verify that each one
fulfills its responsibility
Testing: Integrate modules and the increasingly large system

Analysis
Design
Implementation
Testing
45
Structured models: Waterfall
46
46
Analysis
Design
Implementation
Testing
Pro Contra
Clear sequence of specific tasks Inflexible partitioning into stages
Complete, well-defined products Insensitive to changing requirements
Easy to manage process model
High-risk due to big bang
integration
Paradigm shift
Dissatisfaction with the overheads of structured models
The aims of agile methods are to
Reduce overheads in the software process (e.g., by limiting
documentation)
Be able to respond quickly to changing requirements without excessive
rework
Thus, agile methods
Focus on the code rather than the design
Are based on an iterative approach to software development
Are intended to deliver working software quickly
Evolve small pieces of quickly delivered software to meet changing
requirements
47
Agile models
Family of development processes, such as
Extreme Programming (XP)
Scrum
Focus on new paradigms in software engineering
Rapid development
Frequent releases
Reducing process overheads
Producing high-quality code
They involve the customer
directly in the development
process
Analyze a little, design
a little, code a little

Analyze Design
Code / Test
48
Agile models: Scrum
Outline planning and architectural design
Find and outline the requirements
Identify the main abstractions of the software system and design the
architecture
Assess, Select, Develop, Review
Assess the requirements, select and prioritise the most important ones,
develop , review / test / bugfix
Repeat the previous steps until all requirements are done

4
9
Outline planning
and architectural
design
Project closure
Assess Select
Review Develop
49
Agile models: Scrum
Pro Contra
Incremental development Frequent refactoring
Strong communication with customer
and in the team
Often used as an excuse for lack of
planning
Functionality is broken down into
manageable pieces
Not (yet) feasible in distributed
projects
Rapid response to chance
Only applicable to small sized
systems
Outline planning
and architectural
design
Project closure
Assess Select
Review Develop
50
What do we know about agile models
Are widely believed to have positively impacted
development performance

Mixed experience in practice suggest presence of
important contingencies

Wide field of different studies
Introduction and adoption
Easy to adopt, but work only for certain types
Human and social factors
Inter-personal skills and trust required
Perceptions of agile methods
Very mixed experiences
Comparative studies
Each with unique strength and weaknesses
Source: Dyb and Dingsyr (2009)
51
Todays session
52
Agenda
6 Summary
Todays session in review
53
Correct and complete requirements are
critical to projects success
Different types of requirement exists
and need to be differentiated clearly
Gathering correct requirements is a
process involving four basic steps
Elicitation
Analysis and specification
Validation
Management
Have basic overview of development
approaches: structured vs. agile
Reflecting on your goals
54
Your goals
Today
HWS 2013 - DeMIS Section A.2
Questions, Comments, Observations
55
55 HWS 2013 - DeMIS Section A.2
Readings for block A
Please prepare those readings until the exercise of block A

Subramanyam, R., Weisstein, F.L., and Krishnan, M.S. 2010. "User
Participation in Software Development Projects," Communications of the
ACM (53:3), pp. 137-141.
Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Mnch,
J., Rombach, D., and Trendowicz, A. 2010. "Linking Software
Development and Business Strategy through Measurement," IEEE
Computer (43:4), April 2010, pp. 57-65.
Hofmann, H.F. and Lehner, F. 2001. Requirements Engineering as a
Success Factor in Software Projects. IEEE Software (18:4), pp. 58-66.

Read them until 09/17/2013
Further related papers
Optional readings in case you are interested

Rockart, J.F., Earl, M.J., and Ross, J.W. 1996. "Eight Imperatives for
the New IT Organization," Sloan Management Review (38:1), pp. 43-55
Dyba, T., and Dingsoyr, T. 2009. "What Do We Know About Agile Software Development?,"
IEEE Software (26:5), pp. 6-9.
Ulfelder, S. 2001. The dirty half-dozen six ways IT projects fail and how you can avoid them.
Darwin Magazine (June), pp. 58-64.
Cusumano, M., MacCormack, A., Kemerer, C.F., and Crandall, B. 2003. "Software
Development Worldwide: The State of the Practice," Software, IEEE (20:6), November /
December, pp. 28-34.
Siau, K., Tan, X., and Sheng, H. 2010. "Important Characteristics of Software Development
Team Members: An Empirical Investigation Using Repertory Grid," Information Systems Journal
(20:6), November, pp. 563-580.
Kauppinena, M., Vartiainenb, M., Kontioa, J., Kujalaa, S., Sulonena, R. 2004. Implementing
requirements engineering processes throughout organizations: success factors and challenges.
Information and Software Technology (46:14), pp. 937-953.
Christensen, C. 2013. The innovator's dilemma: when new technologies cause great firms to
fail. Harvard Business Review Press.

These readings offer you a more detailed perspective and will
improve your individual knowledge base of this domain
Next session: 09/17/2013
HWS 2013 - DeMIS Section A.2
References Requirements Engineering
Alavi, M. 1984. An Assessment of the Prototyping Approach to Information Systems Development,
Communications of the ACM (27:6), pp 556-563.
Davis, A.M. 1993. Software Requirements: Objects, Functions, and States. Upper Saddle River, NJ, USA:
Prentice-Hall.
Glinz, M. 2007. On Non-Functional Requirements. Proceedings of the 15th IEEE International Requirements
Engineering Conference, October 15-19, 2007. New Delhi, India. pp. 21-26.
Hofmann, H.F. and Lehner, F. 2001. Requirements Engineering as a Success Factor in Software Projects. IEEE
Software (18:4), pp. 58-66.
IEEE. 1998. Recommended Practice for Software Requirements Specications, IEEE Std 830-1998, The
Institute of Electrical and Electronics Engineers
Kauppinena, M., Vartiainenb, M., Kontioa, J., Kujalaa, S., Sulonena, R. 2004. Implementing requirements
engineering processes throughout organizations: success factors and challenges. Information and Software
Technology (46:14), pp. 937-953.
Ruhe, G. 2005. Software Release Planning, Handbook Software Engineering and Knowledge Engineering - Vol.
3, University of Calgary, Canada.
Smith, R.S. 2011. Writing a Requirements Document. Published: n/a. Retrieved: 2011/09/23. Available at:
http://www.cdl.edu/uploads/Qd/S6/ QdS615B1DcnwRZlnSuTDnQ/writing-requirements.pdf.
Sommerville, I. 2010. Software Engineering (9th edition), Boston, MA, USA: Addison Wesley.
References Development
Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Mnch, J., Rombach, D., and Trendowicz,
A. 2010. "Linking Software Development and Business Strategy through Measurement," IEEE Computer
(43:4), April 2010, pp. 57-65.
Cusumano, M., MacCormack, A., Kemerer, C.F., and Crandall, B. 2003. "Software Development Worldwide:
The State of the Practice," Software, IEEE (20:6), November / December, pp. 28-34.
Dyb, T., and Dingsyr, T. 2009. "What Do We Know About Agile Software Development?," IEEE Software
(26:5), pp. 6-9.
Lambertz, W. 2010. Erfolgreiche Eigenentwicklung, retail technology (2010:01), special reprint.
Laudon, K.C. and Laudon, J.P. 2008. Management Information Systems: Managing the Digital Firm (10
th

international edition), Pearson.
Siau, K., Tan, X., and Sheng, H. 2010. "Important Characteristics of Software Development Team Members:
An Empirical Investigation Using Repertory Grid," Information Systems Journal (20:6), November, pp. 563-
580.
Subramanyam, R., Weisstein, F.L., and Krishnan, M.S. 2010. "User Participation in Software Development
Projects," Communications of the ACM (53:3), pp. 137-141.
Xu, L., and Brinkkemper, S. 2007. "Concepts of Product Software," European Journal of Information
Systems (16:5), pp. 531-541.


Development of Business

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Development of Business

Hochgeladen von

Copyright:

Verfügbare Formate

IS203 Section A.

2 - Requirements Engineering and IS Development

Das könnte Ihnen auch gefallen