Transcript Introduction, Requirements Analysis & Business Process Modeling A

Business Analysis
ITEC 630 Fall 2010
Introduction,
Requirements Analysis
& Business Process Modeling
Prof. J. Alberto Espinosa
A
U
My Background
• Started as New faculty at AU in Fall’02
• Previously at Carnegie Mellon University
• PhD and MS in IS from Carnegie Mellon
• Also, BS Mech Engineering & MBA
• Over 18 years of working experience
• Mostly implementing and managing systems
• And in management
• Specialty: systems implementation and database
• Mostly in international/global contexts
• Teach: Intro to IT, web programming, business analysis, database
• Research focus:
A
U
•
IT support for global & geographically distributed collaboration
•
Most recently: team coordination across time zones
2
Class Web Site
• Current versions of syllabus, class schedule, lecture
notes, and homework assignments will be posted on
the Blackboard class web site.
• Course Syllabus also available at:
http://auapps.american.edu/~alberto/itec630/syllabus.html
• Class Schedule also available at:
http://auapps.american.edu/~alberto/itec630/schedule.html
• All homework assignments, lecture slides, and other
class materials will be available via the Class
Schedule link above, and also via Blackboard
• Class announcements and grades will be available
via Blackboard only
A
U
3
What is business analysis?
“The set of tasks, knowledge, and techniques
required to identify business needs and
determine solutions to business problems.
Solutions often include a systems
development component, but may also
consist of process improvement or
organizational change.”
Source: International Institute of Business Analysis (iiBA)
A
U
4
What is requirements analysis?
Requirements are conditions that a product,
system or component must meet and/or
capabilities it must have to solve a business
problem, satisfy a contract, or meet a standard,
specification or other formally imposed documents
- IEEE
Requirements analysis is one of several
business analysis practices, concerned with
identifying requirements for a business application
implementation.
A
U
5
Our Approach:
A
U
Understand the
business: current
processes,
improvements, etc.
Figure out what the
application will to
do to support these
processes (and the
system qualities)
Business Process
Analysis
Functional and
Non-Functional
Requirements
Analysis
Figure out the
information and
data needs
Information
Analysis
6
ITEC 630:
Business Analysis
Course Roadmap
• Business application development: the context
• Business analysis overview
• Requirements analysis
• Business process analysis
• Requirements analysis and use cases
• Data/information analysis
• Interface analysis
• Project analysis
A
U
7
The Context of
Business Analysis:
“Business Application Development”
A
U
8
ITEC
630
Information Technology (IT) and Business
Business
Applications
Business World
Transactions
Transaction
Processing
ERP, SCM, CRM, etc.
Decision Support
Distributed Collaboration
Enterprise Collaboration
Financial Management
etc.
Information
Server
Appl
Client
Appl
IT
Infrastructure
Microcomputers
A
U
Mainframes
Client/Server
Computing
Database
Routers
DB
DB
Ubiquitous
Computing
Security, (Local/Wide area) Networks
Firewalls
Inter-Networking
(Internet, Intranets)
Virtual Private Networks
Distributed
Computing
“The Cloud
& Web 2.0”
9
What is Information
Technology (IT) for Business?
=
IT Infrastructure: the hardware, system software,
telecommunications/networks and data storage
supporting all business applications
+
Business Applications: software used to manage
particular business functions or processes (e.g.,
accounting, supply chain management)
A
U
10
What is an Information
System (IS) for Business?
An arrangement of
people, business functions, processes,
and IT which interact
to collect, store and process, and store data to
provide information to support
business activities and decisions
It is much more than just IT!!
A
U
11
Information Systems
IT for Business
IT
Infrastructure
(HW, System SW,
database, telecom)
+
Business
Applications
(ERP, CRM, SCM,
Financial Appl, etc.)
+
People,
Processes
& Business
Functions
Information System
=
Business Value !!
A
U
12
Requirements for a Cool House:
(first meeting with the client:
a very high level description of the house)
• 3 bedrooms, dinning room, living room, kitchen,
laundry room, 2-1/2 bathrooms
• Back patio, access from the kitchen
• 2-floors + basement
• 2-car attached garage w/extra room on top & driveway
• Landscaped front yard & small trees in the backyard
• 2 windows, one on each side of front door
• 2 windows on 2nd floor above with 1st floor windows
• 2 small windows above garage on extra room
A
U
A Cool House: A Sketch
(a visual representation to discuss w/client)
A
U
A Cool House: A Scale Drawing
(a more detailed representation to discuss w/client)
A
U
A Cool House: The Blueprints
(very specific dimensions to discuss w/client and then
give to builders for construction: i.e., communicating client requirements)
A
U
SYSTEM DEVELOPMENT
All the activities that go into
producing and IS solution:
0. Vision
1.
2.
3.
4.
5.
6.
Analysis
ITEC
Design
630
Implementation
Testing
Conversion
Production & Maintenance
Degree of ceremony or formality?
Depends on size, risk, etc.
A
U
1. Analysis
A communication exercise between system
users and system developers
An analysis of the “problems” to be solved by
an information system
Developing an understanding of “the work”
that the system needs to perform
Developing an understanding of “what” the
system needs to do
Implication:
o
A
U
Understanding the business problem is critical
before offering solutions
18
2. Design
An analysis of the “solutions” to the problems
identified during systems analysis
Developing and understanding of “how” the system
needs to do what was identified during systems
analysis, per the “requirements specification”
Implication:
o
A
U
Can’t design a solution until you’ve analyzed the problem
19
3. Implementation
Selection, acquisition, production and
assembly/integration of the necessary
components of the system
For systems that require software development,
translating the conceptual design into specific
software instructions to accomplish the work.
Implications:
o
A
U
o
Can’t purchase off-the-shelf software until you’ve
until you’ve analyzed the requirements
Can’t build an application until you’ve designed
20
4. Testing
Test Types:
• UNIT TESTING: each part of the system works well individually
• SYSTEM TESTING: all the parts of the system work well together
• REGRESSION TESTING: new parts of the system work well with
the existing system
• ACCEPTANCE (USER) TESTING: By users and/or clients
• BLACK BOX TESTING: Testing if the system does what is
supposed to, per requirements specifications, without inspecting
the internals of the system
• CLEAR BOX TESTING: Inspecting and testing the internals (e.g.,
code inspections) of the system (opening the black box)
Implication:
o
A
U
Analysis artifacts (e.g., use cases) can be used for testing
(e.g., acceptance and black box testing with “test cases”)
21
5. Conversion (i.e., Installation)
Important Conversion Issues:
• CONVERSION PLAN: Schedule for conversion
• DOCUMENTATION: Description of how system works
• USER TRAINING
Conversion Methods:
• PARALLEL: Old & new run simultaneously
• DIRECT CUTOVER: Risky conversion to new system
• PILOT: Introduce first in one area, domain, location
• PHASED: Implement the system in stages
Implication:
o
A
U
Analysis artifacts (e.g., use cases) can be used to develop
user manuals and other system documentation
22
6. Production & Maintenance
• PRODUCTION:
Review by users & operators
User support
• MAINTENANCE:
Upgrades
Bug fixes
Implication:
o
A
U
o
Requirements are not static, they evolve over time
Features are always added and discontinued
23
EFFORT DISTRIBUTION
Brooks, 1994 (IBM O/S 360)
Systems
Analysis &
Design
Maintenance
33%
Testing &
Integration
A
U
17%
33%
17%
Implementation
Systems Development Models
• Linear Sequential Models
System development progresses in a straight line fashion
• Evolutionary Models
System development is done in iterations
A
U
System Development Life Cycle (SDLC)
or the “Waterfall” Model (Linear Sequential)
Analysis
True
Waterfall
Design
Implementation
Testing and
Conversion
In
reality
A
U
Production &
Maintenance
26
SDLC (“Waterfall”) Model Pros & Cons
Pros:
• Oldest and most widely used model
• Life cycle concept is very useful
• OK when requirements are certain and stable
Cons:
• Early errors detected late are very costly
• Not very useful when requirements are uncertain
• Many real projects rarely follow a sequential flow
• Often difficult to know all requirements early on
• Programmers have to wait until the whole design is finished
A
U
27
Core
Product
Analysis
Design
Programming
Increment 1
Analysis
(new feature)
Testing,
etc.
Design
Programming
Increment 2
Analysis
(new feature)
Design
Testing,
etc.
Integration +
Regression
Testing
Etc.
Programming
The Incremental Model
A
U
Testing,
etc.
(Linear Sequential)
28
Incremental Model Pros & Cons
Pros:
• Core functionality can be provided quickly
• Increments can be planned to manage technical risks
(e.g., increment, evaluate, increment, evaluate, etc.)
Cons:
• Takes a long time to finish entire system
• Later increments may never get done
A
U
29
The Spiral Model (Bohem)
(Evolutionary)
Construction
(Implementation)
A
U
Testing &
Release
(Conversion)
Engineering
(Analysis &
Design)
Customer
Communication
& Evaluation
(Business
Requirements)
Risk
Analysis
Planning
30
The Spiral Model
Pros:
• Each loop allows the team to assess risks and
adjust the plan
• More realistic approach for large projects
• Conceptually sound idea
Cons:
• Not many – the basic concept is widely adopted
• Is the foundation for the Unified Process (UP)
A
U
31
Object-Oriented (OO) Analysis
• Most prevalent software system development
paradigm today
• In which a system is conceptualized by
discovering physical objects that the system
needs to represent – e.g., customers, locations,
students, classrooms, invoices, etc.)
• And discovering their attributes (i.e., data
elements – e.g., name, SSN, etc.) and behaviors
(i.e., programs – e.g., place an order)
• More on OO later in the course
A
U
32
Standards
Standards are necessary when many people are involved in a
system development effort.
There are many types of standards, but two important ones are
standards about: (1) notations and (2) processes
• A notation (i.e., a language) is necessary to describe the
system. Standard notations describe the symbols to use in
models and other analysis artifacts. We will use the UML
(Unified Modeling Language)
• A process is necessary to define the sequence of activities
that will be undertaken to gather requirements and then
design and implement the system: We will use the UP
(Unified Process)
A
U
33
Unified Modeling Language (UML)
• UML a standard for notations and methods to express OO A/D
• UML is the most widely adopted standard diagramming notation to
describe systems today
• Proposed by Booch, Jacobson & Rambaugh (the “Three Amigos”) to
unify their individual (most widely used) notations
See Object Mgt Group site: http://www.omg.org/
• Main purpose of the UML: communication!!
• It is intended for OO Analysis and Design (OO A/D)
• You can do OO A/D without UML using other notations
• Similarly, you can use aspects of UML for non OO A/D
• UML is up to version 2.0, textbook UML 1.3, MS Visio UML 1.2
For more info on UML and versions, see: http://www.kobryn.com/
A
U
34
Important UML Models/Artifacts
To be covered in class:
• Use Cases – a set of scenarios of system uses, each tied
together by a common user goal – all use cases collectively
describe the functionality of the system – each use case describes
a discrete aspect of that functionality
• Use Case Diagrams – a visual model that shows how all actors
(i.e., users and external systems) interact with all use cases of a
system
• Activity Diagrams – diagrams that explain use case workflows
(sometimes useful, but use case text is often preferred)
• Class Diagrams – describes the types of objects in a system and
the static relationships among them
A
U
Other important UML models/artifacts not covered in this class:
• Domain models, interaction diagrams, class-responsibilitycollaboration (CRC) cards, state diagrams, etc.
35
The Unified [System Development] Process (UP)
• A system development process defines the activities
undertaken to build, deploy, and maintain systems
• UP: a popular SW development process used with OO
methods – a derivative of the spiral method
• UP was also developed by the “Three Amigos”
• UML and UP are independent – you can use UML
without UP, or UP without UML, but they were both
conceptualize to work together
• Rational UP (RUP): a refinement of the UP formulated
by the “Rational Corporation” now owned by IBM, widely
adopted today.
See: http://www.rational.com/
A
U
36
Key Aspects of the UP
A
U
• Iterations: “timeboxed” – i.e., of fixed time length of 2-6 or more
weeks – date slippage is discouraged – removing tasks or
requirements from the iteration is preferred
• Workshops: each iteration begins with at 1-2 day workshop to
discuss the scope of the iteration and plan accordingly.
• 4 Phases: inception, elaboration, construction and transition
– this course deals with the inception and elaboration phases
• Disciplines (originally called “workflows” until 2001): a set of
related system development activities (e.g., analysis, design, etc.
– note: these are considered “phases” in the Waterfall model)
• Artifacts: working products such as code, database schemas,
text documents, diagrams, models, etc.
• Development Case: articulates upfront which artifacts (not all
artifacts need to be employed) will be used in the particular
development project
37
Iterations, Disciplines & Workflows in the UP
Incep
A
U
Source: Larman book ch.2, p.21
Elab 1 Elab 2
etc.
38
Development Case (illustration)
Not every artifact is used in every project. The development case articulates the
specific artifacts that will be used on a specific project. This is the development case
we will follow for your projects – marked in bold red:
Discipline
Business Modeling
UP Artifact
Inception
I1
Domain Model
Elaboration
E1..En
Construction
C1..Cn
Transition
T1..Tn
S
Vision
S
R
Use Case Model
S
R
Supplementary Spec
S
R
Glossary
S
R
Analysis
Design
Design Model
S
R
SW Architecture Doc
S
Data Model
S
R
Implementation Model
S
R
R
R
R
R
S
R
Implementation
SW Development Plan
A
U
Testing
Test Model
Dev Environment
Development Case
S
S
R
S – Start; R – Refine
UP Phases
39
Important Things
to Keep in Mind
• Ceremony or Formality:
o
o
•
•
•
•
•
High ceremony: lots of formal deliverables, meetings, etc.
How much? it depends
The right process? it varies for each company
Requirements and Design = communication exercises
No need to use all diagrams or artifacts
No need to note everything, only what is noteworthy
Avoid overdoing requirements (i.e., analysis paralysis):
keep it simple, but accurate
Let’s look at the Class Schedule once again
Let’s look at the Final Project
A
U
40
First, the big picture:
Enterprise Analysis
A
U
41
Information Systems and
Application “Silos”: The Old Way
Silos or
Stovepipes
A
U
42
The New Way:
Focus on Business Processes
A process:
Manner in which work is organized and
coordinated to produce a product or service
• Some business processes take place within a function
• Some others cut across multiple business functions
• Concrete work flows of material, information, and knowledge
• Unique ways to coordinate work, information, and knowledge
• Example: processing a customer order
A
U
43
A Process May Cut Across Multiple Departments
A
U
44
Enterprise Architecture and Business
Process Orientation: The New Way
ITEC 630
Business
Domain
Business
Application
Business
Process
Diagrams
Business Process Model
Data
Models
Information Model
Use Case
Models
Application Model
Organization
Goals
Technology Model
A
U
Enterprise Model
45
EA Process
(Armour et al 1999, TOGAF):
EA Maturity (Ross et al 2006)
Business Silos (i.e., stovepipes)
Standardized Technology
Optimized Core
Business Modularity
Baseline EA
Transition
from Baseline
to Target EA
Target EA
Individual
System
Implementations
A
U
p.46
Business Analysis
A
U
47
What is business analysis?
“The set of tasks, knowledge, and techniques
required to identify business needs and
determine solutions to business problems.
Solutions often include a systems
development component, but may also
consist of process improvement or
organizational change.”
Source: International Institute of Business Analysis (iiBA)
A
U
48
About the Business Analysis Profession
• Business analysts used to be called “systems analysts”
• Business analyst is the preferred title today in recognition of
the fact that business strategies and system implementations
need to be tightly aligned, so the analyst needs to thoroughly
understand business goals, functions and processes, more than
systems per se (CIO Magazine)
• A business analyst works as a liaison among stakeholders in
order to elicit, analyze, communicate and validate
requirements for changes to business processes, policies and
information systems (iiBA)
A
U
• The business analyst understands business problems and
opportunities in the context of the requirements and
recommends solutions that enable the organization to achieve
its goals (iiBA)
49
Business Analysis Skills
Ability to develop a thorough understanding of:
• the requirements to solve a business problem, often
with a system implementation
• how the proposed system or solution will
interoperate or integrate with the existing systems
and technology in which the new system will operate.
• how the proposed system or solution fits the existing
enterprise architecture and business strategies
A
U
• the business problem from multiple perspectives:
business, user, functional, quality of service,
implementation, etc.
50
Business Analysis
Body of Knowledge (BABoK)
See iiBA (BABoK is available for a fee (selected
sections on Blackboard http://download.theiiba.org):
• Business analysis planning and monitoring
• Requirements elicitation
• Requirements management and communication
• Enterprise analysis
• Requirements analysis
• Solution assessment and validation
A
U
• Underlying competencies
51
Requirements Planning and Monitoring
It involves:
• Identifying team roles: project manager, business analysts, developers, quality
assurance analysts, trainers, application architects, data modeler, database analyst,
infrastructure analyst, information architect, subject matter (functional) experts, etc.
• Identifying stakeholders (who will provide requirements information): executive
sponsor, solution owner (client), end users, functional managers, investors, etc.
• Distribute responsibilities amongst business analysts and other team members and
define coordination, team communication and knowledge sharing mechanisms and
processes
• Define risk monitoring and management approach for each identified risk
• Define the requirements and system development method (e.g., traditional, object
oriented, unified modeling language—UML, etc.)
• Define the requirements and system development process (e.g., system
development life cycle, iterative, unified process—UP)
• Manage requirements change and scope: requirements creep is a big problem
• Define and collect project metrics and reporting mechanisms
•
A
U
Other project planning and project management activities
52
Requirements Elicitation
A “key” BA task – it provides the foundation for solutions to
business needs – it helps develop a thorough understanding of the
business process that will be automated and the essential needs of
the system.
It involves:
• Eliciting the these essential needs from stakeholders – dependent on the
knowledge and willingness of stakeholders to share information
• “Trawl” for knowledge: business processes, baseline system, target system
• Methods: interviews, surveys, focus groups, requirements workshops,
observations, prototyping, written documents, etc.
• Analyze all interfaces – human and external systems
• Document (i.e., record) all requirements identified (and the source) –
requirements notes, cards, etc.
• Establish priorities and verification (measurement) parameters
A
U
• Beware of “scope creep”
53
Requirements Management
and Communication
The objective is to develop an accurate understanding of the business
problem and clearly articulate the solution.
It involves:
• Communication skills are critical – two ways: not only clearly articulating
things verbally and in writing, but also listening effectively
• Selecting the appropriate models, artifacts and other requirements documents
formats.
• Describing models and text artifacts clearly, accurately and concisely
• Key deliverable: “requirements specification” representing the BA’s
“demonstrated understanding” of the business and processes that need to be
handled by the system and its necessary capabilities.
• These specs will serve as the foundation for: effort estimation, budgeting,
resource allocation, contractual terms, and implementation planning, etc.
• Preparing effective presentations for clients and stakeholders.
A
U
54
Enterprise Analysis
• Enterprise architecture:
o
“The explicit description and documentation of the current and desired
relationships among business and management processes and
information technology.” – U.S. Office of Management and Budget, Circular A-130
o
The blueprint for creating enterprise-wide systems in alignment with
business needs
o
It involves preparing all diagram, models and descriptions of: all business
processes, functions, information and technology infrastructure
o
It often involves analyzing the current architecture, conducting gap analysis
and developing a target architecture along with a transition plan
• The business analyst needs to understand the enterprise strategies, which
provides “the context” in which enterprise analysis is conducted
• In modern, complex, dynamic and fast-paced business environments, the
enterprise strategy and information technology are tightly aligned, but the
strategy evolves rapidly, presenting substantial challenges for business
analysts.
• In large complex organizations, senior business analysts are key participants in
the strategic planning process.
A
U
55
Requirements Analysis
“The objective is to define and describe the characteristics of an
acceptable solution to a business problem, so that the project team
has a clear understanding of how to design and implement it” (iiBA)
It involves:
• Developing analysis models and artifacts
• Can be textual or diagrams – beware of over-diagramming
• And “transitional artifacts” that connect the multiple models – e.g.
CRUD and other matrices
• Methods: business process analysis, object-oriented (OO) analysis,
structured analysis
• Requirements: functional, non-functional, project, assumptions,
constraints, etc.
A
U
56
Solution Assessment & Validation
Two key aspects: (1) evaluation if the proposed solution meets business needs
(and the architecture analysis) and (2) if the solution was implemented correctly
(per requirements)
Evaluate proposed solution, it involves:
• Requirements reviews to evaluate if they are accurate, complete, clear, non-redundant,
consistent (with architecture and business needs), feasible, correctly prioritized, etc.
• Obtaining signoff from clients and stakeholders – helps buy in and reduce “feature churn”
Evaluate correct implementation, it involves:
• Working with Quality Assurance teams
• Mapping analysis artifacts to design artifacts
• Mapping implemented system features to requirements artifacts
• Black box testing of the system implemented – e.g., using test cases
• Evaluating non-functional requirements and technologies used
• Evaluating usability and interfaces (human and system)
A
U
57
Underlying Competencies
Behaviors, characteristics, knowledge and personal qualities that
support the practice of business analysis, including:
• Analytical Thinking and Problem Solving: creative thinking,
decision making, learning, problem solving, systems thinking
• Behavioral Characteristics: ethics, personal organization,
trustworthiness
• Business Knowledge: business principles and practices, industry
knowledge, organization knowledge, solution knowledge
• Communication Skills: oral communications, teaching, written
communications
• Interaction Skills: facilitation and negotiation, leadership and
influencing, teamwork
• Software Applications: general purpose applications, specialized
A
U
applications
58
Introduction to
Requirements
Analysis
A
U
59
Why are accurate requirements so important?
The cost of fixing and error in requirements is:
Times larger
If discovered during
5
Design
10
Implementation
20
Testing
100
Operations
Bohem, Barry R. 1981. Software engineering
economics. Englewood Cliffs, N.J.: Prentice-Hall.
A
U
60
Errors Propagate and Grow
problem
correct
wrong
requirements requirements
correct
design
correct
code
A
U
wrong
design
design based on
wrong requirements
wrong
code
code based on
wrong designs
code based on
wrong requirements
Requirements Analysis is
Key to Successful Development

Several studies have documented that requirements
errors cost the most and that poor requirements are
the main cause of software failure
GAO’92; Faulk’92; Bohem’81; Curtis’88
“The hardest single part of building a software
system is deciding what to build. ...No other part of
the work so cripples the resulting system if done
wrong. No other part is more difficult to rectify later.”
Fred Brooks (1987)
No Silver Bullet: Essence and Accidents of SW Engineering
A
U
62
Sources of Requirements
• Users, Customers, other Stakeholders
(e.g., employees, management, selected customers)
• Standards (e.g., GAAP)
• Policy/Legal (e.g. government regulations)
• System Documentation
(e.g. current system being replaced, could be manual)
• Business Process Documentation
(e.g. current business memos, manuals, practices)
• Subject Matter Experts
(e.g. experts on the business domain)
A
U
63
Role That Good Requirements Play
• For clients: requirements describe what will be
developed and perhaps provide a contractual basis
for the development
• For project manager: provide a basis for project
planning and measuring progress
• For the developers: provide the functionality to be
designed and coded
• For testers: provide the basis on which test
• For users: documentation and training
A
U
64
Capturing Requirements is Difficult
Need to:
• Find out what is required by/from the system
• Understand these requirements and their implications
• Communicate (text and models) this understanding to
users, customers, designers and other stakeholders
• Manage them – i.e., record them in a traceable manner
and ensure that as requirements change, they are
updated and the impact of the change is understood
• Quality and fit – i.e., ensure that system meets the
requirements
A
U
65
Interviews
• Interviews should be carefully planned
• Interview Process model
o
o
o
o
o
o
A
U
Determine who to be interviewed
Prepare for, plan & schedule each interview
Open the interview:
introduction, purpose, permissions (to tape, etc.)
Conduct the interview:
semi-structured, open ended questions, mail questions in
advance, let users digress, don’t agree or disagree on
anything (just capture)
Close the interview: summarize things, confirm facts
Follow up: resolve conflicts; close-ended questions
66
Requirements Workshops
A
U
• Approx 2 days before each UP iteration
• Multiple stakeholders participate:
multiple perspectives of the system
• It fosters clear communications between
Requirement Analysts, users and other stakeholders
• Fosters sense of participation and project ownership
• Helps accelerate requirements elicitation process
• Facilitators are often used
• Need a scribe to document the discussion
• Need rules for participation and problem resolution
• Need a process that fosters preparation
• Pre-specify expected deliverables
• Use artifacts that foster communication with the client:
A Business Process Model (or Map) is an excellent tool
for this
67
“Trawling” for Knowledge:
Eliciting Requirements






A
U
“Running a net through the organization to catch every possible
requirement source” (Robertson & Robertson)
With experience, you learn where to fish to find what you want
Start with documents from the project “blastoff” meeting with
your client
Elicit further requirements through: interviews, requirements
workshops, questionnaires, observations, job protocol analysis,
prototyping, review of existing documents
Systematically “catch” and record all requirements
Document anything that sounds like a requirement using an
organized form or template like: the Volere Requirement Shell
68
Volere Requirements Shell
A
U
Examples:
• Functional
• Non-functional
• Project constraints
• Design constraints
• Business issues
• Project issues
Requirements Defined
A
U

In simple terms, requirements are things the product
needs to do (i.e., useful functionality for its user) and
the capabilities and qualities that it must have (i.e.,
non-functional)

IEEE definition:
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 documents
3. A documented representation of a condition or
capability as in (1) or (2)
70
Requirements Analysis
Find, understand, record and communicate:
•
Functional Requirements (behavioral)

•
Non-functional Requirements (non-behavioral)

•
The qualities of the system (e.g., speed, reliability, capacity)
Other Requirements

A
U
What the system needs to do
Project requirements, risk, costs, deliverables, deadlines, etc.
•
Prepared using a “System Requirements Process”
•
Articulated in a “System Requirements Specification”
71
Functional Requirements
•
•
•
•
Are descriptions of “the work” the system needs to do
Articulated with text and/or models/diagrams
When you think of functional requirements think of verbs
The functional requirements define the “functional scope” of
the application – i.e., where its responsibility begins and ends
• We will use “use case” analysis to define the functional scope
of applications in this course
• Your articulation of functional requirements becomes your
“demonstrated understanding” of the business processes
your system needs to automate – Eric Bristow, Deloitte Consulting
• Generally, functional requirements will take the largest share
of time to gather – you must understand quite well what the
system needs to do.
A
U
72
Non-Functional Requirements
• Are “the properties that your product must have …
they are not part of the fundamental reason for the
product’s existence, but are needed to make the
product perform in the desired manner … they
describe the experience that the user has while
doing the work” – Robertson & Robertson
• Functional requirements  think of verbs
• Non-functional requirements  think of adjectives
• Non-functional requirements generally are better
known by clients and will not take as long to
determine – but have huge implications on system
cost.
A
U
73
Examples of
Non-Functional Requirements
•
Look and Feel – interface, style
•
Usability – ease of use/learning, personalization,
access considerations, interface features
•
Performance – speed, latency, reliability, availability,
capacity, scalability, etc.
Operational – technical/physical environment
•
•
A
U
•
•
•
Maintainability and Portability – ability to fix,
support, and port the system
Security – access, integrity, privacy, etc.
Cultural and Political
Legal
74
Non-Functional Requirements Conclusion
• Critical to successful development of the system
• Misunderstanding of these requirements can
significantly impact cost and feasibility of system
• Difficult to represent in object models and use
cases.
• Typically represented using some form of text in
the requirements, then realized in the architecture.
• Can be hard to validate, unless they are quantified –
i.e., fit criteria
A
U
75
General Qualities of Good Requirements
A
U
•
•
•
•
•
•
•
•
•
•
•
•
Correct
Unambiguous
Complete
Verifiable (i.e., fit criteria)
Consistent
Understandable
Modifiable
Traceable
Design independent
Concise
Organized
Prioritized
76
Other Requirements Issues
• Mandated constraints: are indistinguishable from
design decisions, except that they are requirements
mandated by the client – e.g. use Oracle platform for all
databases; develop a web based application
• Facts: are conditions about the system’s external
environment (e.g., actors, systems, organizations)
known to be true – they are different than mandated
constraints in that they are about the application context,
but not mandated by the client the system– e.g., visually
and hearing impaired users will need to use
• Assumptions: are conditions about the system’s
external environment (e.g., actors, systems,
organizations) believed, but not confirmed to be true –
A
U
e.g., all users speak English
77
The Requirements Specifications
Robertson & Robertson’s “Volere Specifications Template (on Blackboard)”





A
U
Project Drivers:
purpose, stakeholders, actors
Project Constraints:
constraints, glossary, assumptions
Functional Requirements:
use cases, class diagrams
Non-functional Requirements:
“ilities” & other qualities
Project Issues:
off-the-shelf, costs, risks, etc.
Template for this course’s project: we use an adaptation
(simplified version) of the Volere Template
78
Business Process
Modeling
A
U
79
A (simplified) Deloitte BPM Example
Project Baselining Flow Chart
Business Office
Project
Project Director
Manager (PM)
Initiation Phase
A
U
10
Is Prioritization Yes
required?
Baseline Phase
2
Enter Priority Data
No
Start
1
New project
developed and
approved
4
Back to PM
8
Enter Project Data
9
Prepares Project
Schedule and cost
Baseline Report
End
No
3
Receives project
information from
PM
5
Enters project data
into Finance
Module
7
Receives award
information from
Acquisitions
80
Business Process Model
• The system you are gathering requirements for will
automate one or more business processes
• Therefore, it is very important that the requirements
analysts and clients develop common ground on what
these business processes are
• The best way to achieve this is to develop a business
process model and get the client to sign off on it
• The idea is to develop a vision of “the work” that needs to
be done, looking ONLY at the business aspects of the
process
• A business process model or map (BPM) fosters
communication between the requirements team and the
client; and within the team
• It provides an excellent starting base to begin to articulate
the system requirements
A
U
BPM Symbols
A
U
Question ?
Yes
No
Function A
• Terminator: start and end points in a process – it only
has one input or one output, not both.
• Process step: a specific step in the process – it MUST
have one input and one or more outputs
• Pre-defined process: like a process steps but it
actually incorporates multiple steps. They are useful to
simplify the diagramming of complex processes
• Decision: a question or a branching in the process flow
it MUST have one input and one output for each
possible decision outcome
• Process flow: a directed arrow that specifies the
process sequence
• Functional bands or swim lanes: show which
departments, units or functional roles are associated
with different parts of the process
• Phase or separators: use to differentiate different
phases of the process
82
BPM Symbols (Cont’d.)
• Parallel Processing: use these to branch out into
multiple parallel flows or to merge them into a single
flow.
• Off-Page Reference: use it to link to another page
• On-Page Reference: use it to link to other parts of the
diagram within the page to avoid line crossings and
complex flows
• These are older legacy symbols frequently used in
flowcharts, which you can also use in BPM’s, but I
suggest adding notations for these symbols for a nontechnical or younger audience :
Manual
Process
Printed Output
Screen Display
Data
P.2
A
Data
Manual Input
• More BPM symbols:
http://www.breezetree.com/article-excel-flowchart-shapes.htm
A
U
83
“Cross Functional Flowchart” (non-UML) BPM Symbols
Process Name
Swim Lane or
Functional
Band Name
A
U
Phase 2 Name
A
Parallel
Operations
Proc
Outcome A
Start
Decision 1?
Proc
Proc
Outcome B
Proc
Swim Lane or
Functional Band
Name
Swim Lane or Functional
Band Name
Phase 1 Name
A
Outcome C
Process 2 if
Decision 1 is Yes
Yes
Page 2
Process 1
Connect from/to another
page
Decision 1
Printed output
No
Process 2 if
Decision 1 is No
Annotations: use this
symbol to embed
comments
End
Database operation
84
Some Guidelines for Good BPM Modeling
• Process steps:
o
o
Can have more than one input but only have one output – if you think you need
two outputs you probably need a decision symbol that evaluates which output path to
follow
Must have at least one input and one output – unconnected process step boxes
without input and output are incorrect!!
• Pre-Defined Process:
o
o
Same as process steps, but can have more than one output
In their detail diagrams, use connector symbols to show where the pre-defined
process connects to other sub-processes.
• Decision (diamond):
o
o
o
Have one input and at least two possible outcomes
It may have more than two outcomes but this may point to more complex process
steps that are better described in a “pre-defined process”
All outcomes MUST be labeled (e.g., “yes”, “no”, “option 1”)
• Process flows:
o
Must connect two symbols (process box, decision, start, end, etc.) – unconnected
flows are incorrect.
• You can add other symbols to add clarity (e.g., page references, connectors,
database, printout, etc.); label these symbols as needed for clarity
A
U
85
Some BPM Guidelines
• BPMs are used to document business processes, NOT
systems actions – focus on understanding and documenting
what people do and what the key processes are, rather than
what the system solution will do.
• In other words, you need to understand the business
processes before you can suggest a solution.
• It often helps to distinguish the baseline BPM (what the client
does) from the target BPM (what the client wants or your
proposed solution). You can add notations and other symbols
to distinguish baseline from target processes
• It may also help to distinguish processes that are carried out
manually from those that are handled by applications
• More importantly, this is NOT hard science – if you can do
anything to add descriptive clarity to your BPM, by all means
A
U
86
More BPM Diagramming Rules
• All BPM diagrams have one start and one end symbols.
• If there are two or more distinct sub-processes, it is OK to
break up the BPM into two sub-models, but each must
have a start and end symbols.
• If you have many sub-processes you can create one
master BPM that includes “Pre-Defined Process” symbols
and then create a separate BPMs for each of these predefined sub-processes.
• You can include many symbols in the diagram to add
clarity to your process descriptions. Some symbols just add
clarity (e.g., comment, database store, printout), whereas
others have very specific rules on how to use them.
A
U
• More BPM guidelines: http://www.edrawsoft.com/flowchart-symbols.php
87
BPM Example - Current
Cross-Functional Flowchart
A
U
88
More Guidelines
(see vehicle prior rental example)
• If there is a process already in place (i.e., baseline) and you are
proposing process improvements (i.e., target)

Differentiate the two in your diagram or have two separate diagrams
• If your solution includes building a system but there are process
steps that will not be handled by the system, your diagram(s)
should distinguish the manual steps from those to be handled by
the system
• It is important to number or label all the process steps (P1, P2,
etc.) and the decision steps (D1, D2, etc.) to:
o
o
A
U
Facilitate reference to specific parts of the process
To cross reference with other models  using “transitional
artifacts” (more on this later)
89
BPM Example – Proposed
A
U
90
Some BPM Diagramming
Guidelines for Complex BPMs
• If the BPM is complex and there are two or
more distinct sub-processes, it is
recommended to break up the BPM into two
sub-models, and then:
o
o
A
U
Prepare a high level or master diagram that shows
all the sub-processes using pre-defined process
symbols
Prepare a separate detail diagram for each subprocess
91
Master BPM Example
Each Pre-Defined Sub-Process Box Has its Own BPM Diagram
“Pre-Defined Process” symbol used for more complex process
steps with a page connector. In this case P.3 should have a
separate BPM showing all the steps of this pre-defined process
Master Business Process Model
Business
Business
Process33
Process
Start
Phase 1
Sub-Process
1.1
Begin
Phase 2
Decision A
End
No More
P.2
Business
Business
Process11
Process
Business
Business
Process22
Process
Please Proceed
A
U
Which subprocess?
Sub-Process
2.1
Sub-Process
Step A
End
P.3
Option A
Sub-Process
Step B
Decision B
Sub-Process
3.2
P.4
Option B
Regular process step symbol
used for simpler steps
Page symbol to help navigate
to the sub-process BPM
92
BPM Example – Proposed
Vehicle Prep
Paperwork
Vehicle
Delivery
A
U
93
BPM Example – High Level Diagram
A
U
94
BPM Example:
Defined Process
Details
A
U
Connector