Financial Analysis of Berlin Brandenburg AirportTotal of 3000 wo

Financial Analysis of Berlin Brandenburg Airport
Total of 3000 words
Two topics of financial analysis to be included (compare and
contrast) OR one topic in details
Professional Academic language (critical writing) for Masters
Degree
Harvard Referencing
Use ratios other than Net Profit Margin, Current Ratio, Earnings
per Sharing.
https://www.berlin-airport.de/en/press/publications/
a. Introduction 300 words: (not limited to the below)
- Scope of what you are looking at (interested in/ included in),
what I’m not looking at ( to let the grader know the
expectations from this study- what will be included in the report
and what not will not be included because of what?-),
- Context
- Brief description of the project,
- how im going to do it (im going to look at this project through
…. (for example financial analysis/ control…) through these
…..
b. Budgets and Financial Control theories- 600 words: (not
limited to the below)
· Theories Definitions (which will be used in the report)
(academic authors: references are only from Academic Journals)
· Literature review (discussion)
· Methodologies
· Background to the context you have chosen
·
c. Application of Budgets and Financial Control theories 1200
words (not limited to the below)
· Apply theories in calculations (calculations)
· Analysing (overrun? To control the project to bring it back on
the track?............ , many things to be discussed)

· The part of numbers (pdf) should be included as appendix.
· For ratios analysis, minimum three years to be presented to
analyse the results
· Process mapped to show the approach I have used
d. Future Directions and Recommendations 600 words (not
limited to the below)
· What could be done differently,
· Particularly follow/ agree with theories.. play the theorises,
the company did this but the academic literature says that this
can be done and improve this and that.
e. Conclusion 300 words
-Do not give an undergrad solution, not describing only, but a
brief description with the situation in a critical way.
Chapter 8:
Understanding User Requirements
1
© Karl E. Wiegers
-oriented world,
extended for general system analysis and UI design.
• Use case describes a sequence of interactions
between the software system and an external actor
(scenario) to achieve a common goal/purpose.

• There can be multiple scenarios for a use-case
• The names of the use cases are typically written in
the form of verb followed by an object.
2
3
(CTS)
Some Airline Use Cases
a reservation.
4
iagram
provides high level visual representation of user requirements
5

Primary actor
Initiates
Extend: Can be extended to
another usecase
More example: ATM
6
Include: subtask
relationship
7
uses = includes
8
9
- preferably as a short,
active verb
phrase.

This is
usually an expanded version of what you entered in the “Title”
field.
or a software/hardware system that
interacts with your system to achieve the goal of this use case.
first event
in this use case.
all the
events
in this use case have taken place.
field
contains the example from our previous post - i.e. the flow of
events
from preconditions to postconditions, when nothing goes wrong
Extensions (Alternative Flow & Exceptions) : Describe all
the
other scenarios for this use case - including exceptions and
error cases.
-explanatory.
10
Activity Diagram to show the flows:

11
12
Use Case Example:
13
Another Example:
14
15
Use Case Description for an ATM
Name: Withdraw Cash
Actor: Account Owner
Description: The Account Owner withdraws a specific amount
of cash from
a specified account.
Preconditions:
1. The Account Owner is logged in to the ATM.

2. The Account Owner has at least 1 account with a positive
balance.
3. The ATM contains cash.
Postconditions:
1. The requested amount of cash has been dispensed.
2. The account balance is reduced by the withdrawn amount
plus any fees.
3. The ATM cash balance is reduced by the withdrawn amount.
Priority: High
16
Normal Flow:
1. Account Owner selects Withdrawal action.
2. System displays user’s accounts.
3. Account Owner selects desired account.
4. System asks user to choose amount to withdraw from a list.
5. Account Owner chooses amount to withdraw.
6. System dispenses cash.
7. Account Owner removes cash from dispenser.
Alternative Flows:

at step 4, actor can choose to enter a custom amount and join at
step 6
Exceptions:
amount is not a multiple of $20.00
amount exceeds $400
amount exceeds account balance
amount exceeds cash available in ATM
indicate the step number where the exception
could take place and how the system handles it 17
or part of the use case, e.g., certain people can
perform specific flows (Admin vs, regular user)
• Conversely, from use cases, some BT maybe
drawn
18
• Identify the actors first, then layout the business

processes supported by the system and define
the use cases for activities where actors and
systems interact
E.g., purchase-a-ticket etc
• Create a specific scenario to illustrate each
business process, then generalize the scenarios
and then identify actors
e.g., assign_a_seat
19
“what task must be performed to
complete this process or convert input to
specific output”
e.g., generate_profit_report
the system must respond, then relate this
event to an actor
e.g., sound-alarm
20
• Use CRUD analysis to identify data
entities that require use cases to create,
read, update, delete it.

e.g., change_reservation,
cancel_reservation
• Examine the context diagram, and ask
“what do each external entities want to
achieve with the help of the system?”
e.g., order_a_book
21
Work Products
22
-Case Traps to Avoid
-cases
-cases
nderstand.
-priority use cases.
23

Questions to ask.
the use case clear?
use case?
ined
with others?
verifiable, and feasible?
24
behavior and appearance
with internal behavior, algorithms, storage
◦ Use cases include functional requirements
◦ SRS document includes the write-up of use cases.
25

User Stories for Agile Development (V)
http://www.youtube.com/watch?v=NzSsE37opB0
26
Use Case and User Stories (V)
http://www.youtube.com/watch?v=GoudHe5nxfk
END
27
Chapter 9:
Business Rules
© Karl E. Wiegers
1
2

9.1 Classifying Business Rules
3
4
- Simple truths
- Associations and relationships
often appear in data models
5
Restrictions on systems and users
“Must,” “must not,” “may not,” “only,”
“if”
6
Conditions that trigger activities
7

Facts derived from other conditions
8
Formulas, algorithms, tables
9.2 Discovering Business Rules
constraints on process:
◦ Why must we do it that way?
◦ What does the government want?
◦ How is that calculated?
◦ What causes changes to objects?
◦ How does the system know what to do next?
◦ What can and cannot happen? (and why)
◦ What may the user do next?
◦ How are these pieces of data related?
9
10
9.3 Documenting Business Rules
-wide catalog:
◦ ID (for easy reference)

◦ Definition
◦ Type
◦ Probability of change (static/dynamic)
◦ Source (company policy, public law, agency
regulation,…)
11
12
E N D
13
Chapter 10:
Documenting the Requirements
© Karl E. Wiegers
1
2

10.1 Software Requirements Specification (SRS)
3
4
(NEW)
NEW
NEW
Template 2
5
6
Template 3
May be slight modified in our
project this semester!!
7
1. Introduction
1.1 Purpose

<This subsection should
a) Delineate the purpose of the SRS; b) Specify the intended
audience for the SRS>
1.2 Scope
a) Identify the software product(s) to be produced by name
(e.g., Host DBMS, Report Generator, etc.);
b) Explain what the software product(s) will, and, if necessary,
will not do;
c) Describe the application of the software being specified,
including relevant benefits, objectives, and goals;
d) Be consistent with similar statements in higher-level
specifications (e.g., the system requirements
specification), if they exist>
1.3 Definitions, acronyms, and abbreviations
<This subsection should provide the definitions of all terms,
acronyms, and abbreviations required to
properly interpret the SRS. This information may be provided
by reference to one or more appendixes in the
SRS or by reference to other documents.>
1.4 References
a) Provide a complete list of all documents referenced
elsewhere in the SRS;
b) Identify each document by title, report number (if
applicable), date, and publishing organization;
c) Specify the sources from which the references can be
obtained.
This information may be provided by reference to an appendix
or to another document.>
1.5 Overview

a) Describe what the rest of the SRS contains;
b) Explain how the SRS is organized.>
Template 3 Explanations:
May be slight modified in our
project this semester!!
8
2. Overall Description
2.1 Product Perspective
<Describe the context and origin of the product being specified
in this SRS. For example,
state whether this product is a follow-on member of a product
family, a replacement for
certain existing systems, or a new, self-contained product. If the
SRS defines a component
of a larger system, relate the requirements of the larger system
to the functionality of this
software and identify interfaces between the two. A simple
diagram that shows the major
components of the overall system, subsystem interconnections,
and external interfaces can
be helpful.>
2.2 Product Features
<Summarize the major features the product contains or the
significant functions that it
performs or lets the user perform. Details will be provided in
Section 3, so only a high level
summary is needed here. Organize the functions to make them

understandable to any
reader of the SRS. A picture of the major groups of related
requirements and how they
relate, such as a top level data flow diagram or a class diagram,
is often effective.>
2.3 User Classes and Characteristics
<Identify the various user classes that you anticipate will use
this product. User classes
may be differentiated based on frequency of use, subset of
product functions used,
technical expertise, security or privilege levels, educational
level, or experience. Describe
the pertinent characteristics of each user class. Certain
requirements may pertain only to
certain user classes. Distinguish the favored user classes from
those who are less
important to satisfy.>
9
2.4 Operating Environment
<Describe the environment in which the software will operate,
including the hardware
platform, operating system and versions, and any other software
components or
applications with which it must peacefully coexist.>
2.5 Design and Implementation Constraints
<Describe any items or issues that will limit the options
available to the developers.
These might include: corporate or regulatory policies; hardware

limitations (timing
requirements, memory requirements); interfaces to other
applications; specific
technologies, tools, and databases to be used; parallel
operations; language
requirements; communications protocols; security
considerations; design conventions or
programming standards (for example, if the customer’s
organization will be responsible
for maintaining the delivered software).>
2.6 User Documentation
<List the user documentation components (such as user
manuals, on-line help, and
tutorials) that will be delivered along with the software.
Identify any known user
documentation delivery formats or standards.>
2.7 Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that
could affect the
requirements stated in the SRS. These could include third-party
or commercial
components that you plan to use, issues around the development
or operating
environment, or constraints. The project could be affected if
these assumptions are
incorrect, are not shared, or change. Also identify any
dependencies the project has on
external factors, such as software components that you intend to
reuse from another
project, unless they are already documented elsewhere (for
example, in the vision and
scope document or the project plan).>

10
3. Use Case Diagram with Use-case descriptions
<Use provided form for each use-case description>
11
4. User Interfaces
<Describe the logical characteristics of each interface between
the software product and the users.
This may include sample screen images, any GUI standards or
product family style guides that are
to be followed, screen layout constraints, standard buttons and
functions (e.g., help) that will appear
on every screen, keyboard shortcuts, error message display
standards, and so on. Define the
software components for which a user interface is needed.
Details of the user interface design
should be documented in a separate user interface
specification.>
4.1 Hardware Interfaces
<Describe the logical and physical characteristics of each
interface between the software product
and the hardware components of the system. This may include
the supported device types, the
nature of the data and control interactions between the software
and the hardware, and
communication protocols to be used.>

4.2 Software Interfaces
<Describe the connections between this product and other
specific software components (name and
version), including databases, operating systems, tools,
libraries, and integrated commercial
components. Identify the data items or messages coming into
the system and going out and
describe the purpose of each. Describe the services needed and
the nature of communications.
Refer to documents that describe detailed application
programming interface protocols. Identify data
that will be shared across software components. If the data
sharing mechanism must be
implemented in a specific way (for example, use of a global
data area in a multitasking operating
system), specify this as an implementation constraint.>
4.3 Communications Interfaces
<Describe the requirements associated with any communications
functions required by this product,
including e-mail, web browser, network server communications
protocols, electronic forms, and so
on. Define any pertinent message formatting. Identify any
communication standards that will be
used, such as FTP or HTTP. Specify any communication
security or encryption issues, data transfer
rates, and synchronization mechanisms.>
12
5. Other Nonfunctional Requirements

5.1 Performance Requirements
<If there are performance requirements for the product under
various circumstances, state them
here and explain their rationale, to help the developers
understand the intent and make suitable
design choices. Specify the timing relationships for real time
systems. Make such requirements
as specific as possible. You may need to state performance
requirements for individual
functional requirements or features.>
5.2 Safety Requirements
<Specify those requirements that are concerned with possible
loss, damage, or harm that could
result from the use of the product. Define any safeguards or
actions that must be taken, as well
as actions that must be prevented. Refer to any external policies
or regulations that state safety
issues that affect the product’s design or use. Define any safety
certifications that must be
satisfied.>
5.3 Security Requirements
<Specify any requirements regarding security or privacy issues
surrounding use of the product
or protection of the data used or created by the product. Define
any user identity authentication
requirements. Refer to any external policies or regulations
containing security issues that affect
the product. Define any security or privacy certifications that
must be satisfied.>
5.4 Software Quality Attributes

<Specify any additional quality characteristics for the product
that will be important to either the
customers or the developers. Some to consider are: adaptability,
availability, correctness,
flexibility, interoperability, maintainability, portability,
reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and
verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as
ease of use over ease of
learning.>
13
6. Other Requirements
<Define any other requirements not covered elsewhere in the
SRS. This
might include database requirements, internationalization
requirements,
legal requirements, reuse objectives for the project, and so on.
Add any
new sections that are pertinent to the project.>
7. Data Flow Diagram
<Draw the Data Flow Diagrams with at least 2 – 3 levels, i.e.,
level 0 and level
1 and 2>
14
8. Functional Requirements (FRs)

This section describes specific features of the software project.
ONE
8.1 <Functional Requirement #1> - Name
8.1.1 Introduction <describe what this FR does >
8.1.2 Inputs <any input data need to this FR>
8.1.3 Processing <details of how this FR processes>
8.1.4 Outputs <any output data from this FR>
8.1.5 Error Handling <any error conditions and how to handle
these error
conditions>
8.2 <Functional Requirement#2>
…
8.n <Functional Requirement #n>
9. Sequence Diagram
<Draw the interactions among the classes>
10. Class Diagram
<Identify all classes with relationship, attributes and also
services>
15
E N D
Chapter 7:
Requirements Elicitation
1

7.1 Elicitation
constraints of stakeholders.
extract and define requirements.
non-functional requirements.
most challenging and critical, error-prone
and communication intensive aspect of software
development.
2
3
7.2 Elicitation Techniques
Analysis
Elicitation Techniques(V)

4
• Traditional approach to communicate
with a user or small group
• Structured vs. Non-structured
(pre determined questions)
Vs
(open questions)
5
Encourage stakeholders collaboration in
defining the requirements.
stakeholders and formal roles such as
◦ Facilitator—to lead the process.
- Keeping to the agenda
- Staying in scope
- Moving items to the parking lot
- set Time limits
- Drawing out nonparticipants
◦ Scribe/recorder—to write things down
6

Facilitator’s role is crucial
- Everyone reads vision and scope document
before workshop
- Periodically check requirements for compliance
- Stay on topic, leave other requirements for other
days
7
-lots for later considerations.
- Don’t forget random but important
information just because it seems off-topic
- Write it down—don’t lose it
so person knows he isn’t being ignored
8
Some Ground Rules for sessions

k to the agenda,
9
Is a representative group of users who
convene in a facilitated meetings to
generate input and ideas on product
functionality and quality requirements.
Participants normally do not have
decision making authority for
requirements
10
• Sometimes requirements can be
generated by observing how the users are
performing the tasks
• Can be time consuming and disruptive to
the user
• Typically important or high-risk tasks are
selected
• Can be silent or interactive

11
is a technique where the existing UI is
examined to discover the user and functional
requirements
Refers to examining any existing
documentation for potential software
requirements.
E.g., business processes, decision rationals,
Forms, user manual etc
12
Are a way to survey large group of users to
understand their needs across
geographical boundaries.
• Open-ended vs. Closed Questions
• Well-written questions are key to the
success (GIGO)
13

It reveals functional requirements regarding the
exchange of data and services between systems.
• Context Diagram or Ecosystem maps are
good indicators for the start
• Can also find the validation criteria for
Data being exchanged
14
7.3 Planning Elicitation
Elicitation efforts
licitation risks
(see next pages)
15
16

7.4 Preparing for Elicitation
- Need to decide on the scope taking into
account how much the time is available.
- Align the scope with the overall project scope
defined in the business requirement
- Agenda should be itemized with topics to be
covered, time available for each topic, and
objectives.
17
Schedule the physical resources needed, such as
rooms, projectors, tele-conferencing needs, etc
Key to success. Usually prepare open-ended
Questions, such as why?, how? Etc
serves as a starting point.
“it is easier to revise a draft model than to
create from scratch”
18
7.5 Perform the Elicitation Activities

- Explain the approach/technique being
used
- How the information will be captured and
reviewed later
19
Assign a scribe who does not take active role
It should contain: attendee list, invitee not
attended, decisions made, actions to be taken,
division of tasks, outstanding issues, high points
of key discussion
Use white boards, white papers, sticky notes and
markers.
Use 4 walls to draw diagrams and create lists of
ideas, issues etc
20
7.6 Follow up after Elicitation
- Review and update notes soon after the session is over

while memory is still fresh
- keep the original, raw notes, just in case
- Soon after, share the notes with participants for review
- Consider to share the notes who did not participate
21
- Examine Any items that need further
explanation
- See if any knowledge gaps encountered
- Examine the “parking lot”
22
7.7 Classifying User Input
The all kinds of user input needs to be classified.
—financial, marketplace,
benefits
Scenarios)—user goals, paths to goals
—policies, laws and regulations,
formulas
—observable behavior
of system

23
—speed, ease of use, robust,
reliable, secure, efficient (all must be quantified)
al Interfaces—signals, messages, files,
devices, UI standards
—sizes, algorithms, platforms,
languages
—formats, types, ranges,
defaults
Solution
Ideas—could be a valid constraint or
other attribute
24
7.8 Knowing When You’re Done

functional requirements
future.”
25
7.9 Avoid Incorrect/missing Requirements
interpretations
lists, business rules to functional requirements

26
—text, graphics,
tables
matrix—relate actions (use cases, system events
to data
27
Sample CRUDL Matrix in Chemical
ordering system
28
Entity
Use Case Order Chemical Requester

Vendor
Catalog
Place Order
Change Order
Manage Inventory
Report Orders
Edit Requestors
C R R R, L
U, D R R, L
C, U, D
R R, L R, L
C, U, L
C: Create R: Read U: Update D: Delete L: List

Some additional Elicitation Considerations:
them?) to find requirements
—it makes him
guide the discussion (play dumb)
—there should be lots of them
most tedious tasks” or “three most wanted
changes”—ranking helps people think
rk decisions
29
END

30
Chapter 6:
Finding the Voice of the User
1
User Involvement is a critical factor in creating
excellent software. Hence, finding the voice of
the user is critical.
Fundamental Steps in finding the User’s voice
Step 1: Identify user classes
Step 2: Select and work with individuals
Representing each user class
Step 3: Agree on the decision makers of the

requirements
2
6.1 Step 1: Identify User classes
User Classes(V)
3
(manufacturing, legal,
help desk)
(Procurers,
Managers)
(secondary users,
nonhuman)
closely aligned with business objectives

t have
access to the software (thief, unauthorized person etc.)
product is not built to suit them (secondary users)
4
Identify and characterize early
combined
locations
—a description of a
fictional example of each user class

5
• External entities in the context diagram
• See organizational charts
6
E.g., Some user class in Cafeteria Ordering System
A Patron is a Process Impact employee at the corporate campus
in
Clackamas, Oregon, who wishes to order meals to be delivered
from the
company cafeteria.
400 are

expected to use the Cafeteria Ordering System an average of 4
times per
week each (source: current cafeteria usage data). Patrons will
sometimes
order multiple meals for group events or guests.
corporate
Intranet, with 10 percent of orders being placed from home.
me
Patrons will
wish to set up meal subscriptions, either to have the same meal
to be
delivered every day or to have the day’s meal special delivered
automatically.
specific day.
7
anager

• The Menu Manager is a cafeteria employee, perhaps the
cafeteria manager, who is responsible for establishing and
maintaining daily menus of the food items available from the
cafeteria and the times of day that each item is available.
Some menu items may not be available for delivery.
• The Menu Manager will also define the cafeteria’s daily
specials.
• The Menu Manager will need to edit the menus periodically
to reflect planned food items that are not available or price
changes.
8
9
• As the Cafeteria Staff prepare orders for delivery,
they will print delivery instructions and issue delivery
requests to the Meal Deliverer, who is either another
cafeteria employee or a contractor.

• The Meal Deliverer will pick up the food and delivery
instructions for each meal and deliver it to the Patron.
• The Meal Deliverers’ primary interactions with the
system will be to reprint the delivery instructions on
occasion and to confirm that a meal was (or was not)
delivered.
10
Another Example:
6.2 User Representatives:
need to select and work with individuals
representing each user class
• are needed for the development life-cycle:
◦ To provide requirements
◦ To review specifications
◦ To evaluate demonstrations

◦ To perform or witness testing
marketing,…) can mistranslate user needs
11
and Development =>
Product Champion is important
ions (V)
• serves as the primary interface between
members of a single user class and BA.
• collects the requirements from others members
of the user classes and try to reconcile, if any
inconsistencies
• best if they have power to make the decision

12
External Product Champions
contract customer projects
at long-term customers
13
Examples of Product Champion activities:
◦ Refine scope and limitation of the product
◦ Identify external with system interfaces
◦ evaluate the impact on business

◦ transition to new system
14
◦ Collect input from the user class (other
users)
◦ develop scenarios/use cases/user stories
◦ resolve conflicts of requirements with the
user class
◦ define priorities
◦ evaluate prototypes
◦ provide input regarding the performance and
other quality requirements(non functional)
15

◦ Review specifications,
◦ develop acceptance criteria,
◦ provide test data,
◦ do beta testing
◦ write or review manuals,
◦ prepare training,
◦ give demonstrations to user class
◦ Evaluate and prioritize defects and enhancements,
◦ determine change impact on user and business
16
◦ Different tasks, needs, experience, knowledge
◦ There may be subclasses
◦ There may be expert/nonexpert users within class

17
resistance of having PC
requirements cause failures
use an non-valuable one
◦ Champion makes user requirements decisions
◦ Managers retain business decisions—scope,
schedule, cost
18
to Avoid (things to avoid)

views
leave decisions to analyst
represent
19
20
6.3 Agree on the decision makers of the
requirements (Resolving Conflicts )
=> champion decides

=> most favored user, i.e.,
greatest impact on business success
:
=> use business objectives to establish priorities
=> defer to champion
=> customer decides
21
E ND
22

Financial Analysis of Berlin Brandenburg AirportTotal of 3000 wo

Financial Analysis of Berlin Brandenburg AirportTotal of 3000 wo

Recommended

Recommended

More Related Content

Similar to Financial Analysis of Berlin Brandenburg AirportTotal of 3000 wo

Similar to Financial Analysis of Berlin Brandenburg AirportTotal of 3000 wo (20)

More from ChereCheek752

More from ChereCheek752 (20)

Recently uploaded

Recently uploaded (20)

Financial Analysis of Berlin Brandenburg AirportTotal of 3000 wo