Introduction,%20Requirements%20Analysis%20 - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Introduction,%20Requirements%20Analysis%20

Description:

Business Requirements Analysis ITEC-455 Spring 2010 Introduction, Requirements Analysis & Business Process Modeling Prof. J. Alberto Espinosa ... – PowerPoint PPT presentation

Number of Views:321
Avg rating:3.0/5.0
Slides: 97
Provided by: J10355
Learn more at: http://fs2.american.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Introduction,%20Requirements%20Analysis%20


1
Business Requirements Analysis ITEC-455 Spring
2010
  • Introduction, Requirements Analysis Business
    Process Modeling
  • Prof. J. Alberto Espinosa

2
My Background
  • Started as New faculty at AU in Fall02
  • 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
  • IT support for global geographically
    distributed collaboration
  • Most recently team coordination across time zones

3
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.a
    merican.edu/alberto/itec455/syllabus.html
  • Class Schedule also available at http//auapps.am
    erican.edu/alberto/itec455/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

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

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

6
ITEC 455 Business Requirements Analysis
  • Course Roadmap
  • Business application development
  • Business analysis overview
  • Introduction to requirements analysis
  • Business process analysis
  • Requirements analysis and use cases
  • Data/information analysis
  • Interface analysis
  • Project analysis

7
The Context of Business Analysis Business
Application Development
8
Information Technology (IT) and Business
ITEC 455
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)

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

11
Information Systems
IT for Business
People, Processes Business Functions
IT Infrastructure (HW, System SW, database,
telecom)
Business Applications (ERP, CRM, SCM, Financial
Appl, etc.)


Information System Business Value !!
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

13
A Cool House A Sketch (a visual representation
to discuss w/client)
14
A Cool House A Scale Drawing (a more detailed
representation to discuss w/client)
15
A Cool House The Blueprints (very specific
dimensions to discuss w/client and then give to
builders for construction i.e., communicating
client requirements)
16
SYSTEM DEVELOPMENT
  • All the activities that go into
  • producing and IS solution
  • 0. Vision
  • Analysis
  • Design
  • Implementation
  • Testing
  • Conversion
  • Production Maintenance
  • Degree of ceremony or formality?
  • Depends on size, risk, etc.

ITEC 455
17
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
  • 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
  • Cant design a solution until youve 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
  • Cant purchase off-the-shelf software until
    youve until youve analyzed the requirements
  • Cant build an application until youve 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
  • 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
  • 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
  • Requirements are not static, they evolve over
    time
  • Features are always added and discontinued

23
EFFORT DISTRIBUTION
Systems Analysis Design
Maintenance
Testing Integration
Implementation
24
Systems Development Models
  • Linear Sequential Models System development
    progresses in a straight line fashion
  • Evolutionary Models System development is done in
    iterations

25
System Development Life Cycle (SDLC) or the
Waterfall Model (Linear Sequential)
True Waterfall
Implementation
In reality
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

27
The Incremental Model (Linear Sequential)
Core Product
Analysis
Design
Programming
Increment 1 (new feature)
Analysis
Testing, etc.
Design
Programming
Integration Regression Testing
Increment 2 (new feature)
Analysis
Testing, etc.
Design
Programming
Etc.
Testing, etc.
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

29
The Spiral Model (Bohem) (Evolutionary)
Construction (Implementation)
Engineering (Analysis Design)
Testing Release (Conversion)
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)

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

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)

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/

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
  • Other important UML models/artifacts not covered
    in this class
  • Domain models, interaction diagrams,
    class-responsibility-collaboration (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/

36
Key Aspects of the UP
  • 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
Elab 1 Elab 2 etc.
Source Larman book ch.2, p.21
38
Development Case
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 UP Artifact Inception I1 Elaboration E1..En Construction C1..Cn Transition T1..Tn
Business Modeling Domain Model S
Analysis Vision S R
Analysis Use Case Model S R
Analysis Supplementary Spec S R
Analysis Glossary S R
Design Design Model S R
Design SW Architecture Doc S
Design Data Model S R
Implementation Implementation Model S R R
Implementation SW Development Plan S R R R
Testing Test Model S R
Dev Environment Development Case S R
S Start R Refine
UP Phases
39
Important Things to Keep in Mind
  • Ceremony or Formality
  • 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
  • Lets look at the Class Schedule once again
  • Lets look at the Final Project

40
ITEC 455 Business Requirements Analysis
  • Course Roadmap
  • Business application development
  • Business analysis overview
  • Introduction to requirements analysis
  • Business process analysis
  • Requirements analysis and use cases
  • Data/information analysis
  • Interface analysis
  • Project analysis

41
First, the big picture Enterprise Analysis
42
Information Systems and Application Silos The
Old Way
Silos or Stovepipes
43
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

44
A Process May Cut Across Multiple Departments
45
Enterprise Architecture and Business Process
Orientation The New Way
Business Application
Business Domain
ITEC 455
Business Process Model
Information Model
Organization Goals
Application Model
Technology Model
Enterprise Model
46
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
47
Business Analysis
48
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)

49
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)
  • 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)

50
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
  • the business problem from multiple perspectives
    business, user, functional, quality of service,
    implementation, etc.

51
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
  • Underlying competencies

52
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 languageUML, etc.)
  • Define the requirements and system development
    process (e.g., system development life cycle,
    iterative, unified processUP)
  • Manage requirements change and scope
    requirements creep is a big problem
  • Define and collect project metrics and reporting
    mechanisms
  • Other project planning and project management
    activities

53
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
  • Beware of scope creep

54
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 BAs 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.

55
Enterprise Analysis
  • Enterprise architecture
  • 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
  • The blueprint for creating enterprise-wide
    systems in alignment with business needs
  • It involves preparing all diagram, models and
    descriptions of all business processes,
    functions, information and technology
    infrastructure
  • 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.

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

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

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

59
ITEC 455 Business Requirements Analysis
  • Course Roadmap
  • Business application development
  • Business analysis overview
  • Introduction to requirements analysis
  • Business process analysis
  • Requirements analysis and use cases
  • Data/information analysis
  • Interface analysis
  • Project analysis

60
Introduction to Requirements Analysis
61
Why are accurate requirements so important?
The cost of fixing and error in requirements is 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.
62
Errors Propagate and Grow
problem
63
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 GAO92
    Faulk92 Bohem81 Curtis88 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

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

65
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

66
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

67
Interviews
  • Interviews should be carefully planned
  • Interview Process model
  • 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, dont agree or disagree on
    anything (just capture)
  • Close the interview summarize things, confirm
    facts
  • Follow up resolve conflicts close-ended
    questions

68
Requirements Workshops
  • 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

69
Trawling for Knowledge Eliciting Requirements
  • 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

70
Volere Requirement Shell
71
Requirements Defined
  • 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
  • A condition or capability needed by a user to
    solve a problem or achieve an objective
  • 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
  • A documented representation of a condition or
    capability as in (1) or (2)

72
Requirements Analysis
  • Find, understand, record and communicate
  • Functional Requirements (behavioral)
  • What the system needs to do
  • Non-functional Requirements (non-behavioral)
  • The qualities of the system (e.g., speed,
    reliability, capacity)
  • Other Requirements
  • Project requirements, risk, costs, deliverables,
    deadlines, etc.
  • Prepared using a System Requirements Process
  • Articulated in a System Requirements
    Specification

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

74
Non-Functional Requirements
  • Are the properties that your product must have
    they are not part of the fundamental reason for
    the products 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.

75
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
  • Maintainability and Portability ability to fix,
    support, and port the system
  • Security access, integrity, privacy, etc.
  • Cultural and Political
  • Legal

76
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

77
General Qualities of Good Requirements
  • Correct
  • Unambiguous
  • Complete
  • Verifiable (i.e., fit criteria)
  • Consistent
  • Understandable
  • Modifiable
  • Traceable
  • Design independent
  • Concise
  • Organized
  • Prioritized

78
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 systems 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 systems
    external environment (e.g., actors, systems,
    organizations) believed, but not confirmed to be
    true e.g., all users speak English

79
The Requirements Specifications Robertson
Robertsons Volere Specifications Template (on
Blackboard)
  • 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 courses project we use an
    adaptation (simplified version) of the Volere
    Template

80
Business Process Modeling
81
A (simplified) Deloitte BPM Example
82
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

83
BPM Symbols
  • 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

84
BPM Symbols (Contd.)
  • 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 BPMs, but
    I suggest adding notations for these symbols for
    a non-technical or younger audience
  • More BPM symbols http//www.breezetree.com/articl
    e-excel-flowchart-shapes.htm

85
Cross Functional Flowchart (non-UML) BPM Symbols
86
Some Guidelines for Good BPM Modeling
  • Process steps
  • 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
  • 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)
  • 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
  • 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

87
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

88
Some 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 pre-defined 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.
  • More BPM guidelines http//www.edrawsoft.com/flow
    chart-symbols.php

89
BPM Example - Current Cross-Functional Flowchart
90
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
  • Facilitate reference to specific parts of the
    process
  • To cross reference with other models ? using
    transitional artifacts (more on this later)

91
BPM Example Proposed
92
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
  • 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
    sub-process

93
Master BPM Example Each Pre-Defined Sub-Process
Box Has its Own BPM Diagram
94
BPM Example Proposed
Vehicle Prep
Paperwork
Vehicle Delivery
95
BPM Example High Level Diagram
96
BPM Example Defined Process Details
Connector
About PowerShow.com