Please enable JavaScript.

Coggle requires JavaScript to display documents.

BCS - Coggle Diagram

BCS

ESTABLISHING THE REQ.

Identify tacit knowledge and make it explicit

    - a) skills- protocol analysis use to explore unconscious skills
    - b) take-for-granted info: user see it so obvious , not worth mentioning - analyst confirmed it by failing to ask questions on that aspect
    - c) front-story/back-story
         -c1) analyst has to clarify what really happens. Use: shadowing, observation, rich pictures, spaghetti and process modelling
         -c2) analyst has to avoid seeming skeptical - success lies in building a rapport with the key stakeholders and earning their trust.

Framework for Tacit - > Explicit knowledge

       - Step 1: apprentice, observe, recount, eract
       - Step 2: report and record
       - Step 3: disseminate

Identify different viewpoints/perceptions:

  -  use CATWOE technique  to spot different perspective as:  support the product, finding marketing solution, being customer-focused

Framework, define a roadmap for guidance:

   - req. elicitation - drawing out info and req. Use investigation techniques (chapter 5) 
   - req. analysis - examining and organizing the elicited req.
   - req. validation - 
   - req. documentation - 
   - req. management :

Framework for transforming needs into req.
Elicitation stage: known as "req. capture" - means req. were readily available to be spotted and caught. Now, terrm is superside by the "elicitation" due to need of a proactive approach to uncovering the req.

 - req. emerge as a interaction between analyst and user.
 - analyst should help user to visualise the possibilities and articulate their needs.
 -  building the req. list and later developing an organized req. catalogue
 -  create an informal document cu 3 columns: req. , source and comments. Will help to  ensure everything that is raised is documented and the source identified. It is vital to embed traceability in the req.

Analysis stage: analyst has the gatekeeper role

      **A) Ensure req. are well-defined/ well-formed -> apply filters**
        - check for overlapping or duplicate  
        - remove conflict with other req.
        - separate composite desc. into individual req.
        - feasibility evaluation: technical, business, financial
        - confirm relevance by align with business objectives and strategy 
        - formally entered into a req. documents
        - checking for solution - express the req. in terms of solution instead of what the business needs.

       **B) Ensure quality of the req.**  -> ensure req. are SMART defined
       b1) standard of quality: 
            ->  clear - avoid term such as : and, but, except, until  because each of these suggest there is more than one req. in the statement.
            concise - not the place to specify data items, triggers or conditions. will come further down the line.
            ->  consistent - must not contradict other req.
            ->  relevant - distinguish between  a business needs and an individual user's "want".
            ->  unambiguous - if 2 people who read a req. have a different mental picture of what is being asked, then it is ambiguous.
            ->  correct
            -> testable 
            -> traceable : possible only if req. are documented.

     b2) define models 
          - use case diagram  - use to define the scope of the system and features to be delivered
          - business process model - illustrate how the activities and the flow
          - data model - use to clarify the data and the business rules

      **C) Ensure req. are complete -> categorization** 
            - 4 major  category groups:
                 - general(business)
                 - technical
                 - functional
                 - non-functional
          - further sub-groups: 
                - business area, function
                - possible use-case

Validation phase: external stakeholders review the req. in order to agree and sign off

    - question if req. are well defined, clear and complete

Documentation stage:

    - concern with a well organized req. document

Management stage: manage change to the req.

     - ensure req is fully traceable from initial recording to sign-off
     - after sign off req. document become baselined and any change are subject to change manang.

DEFINING THE SOLUTION

Gap analysis between the current and the desired business systems

It is used to examine:

 - the as is and to be business process models
 - the competencies held or required by an individual
 - the IT systems req. and the features offered by an off-the-shelf software pck.

Business Activity Model (BAM) - conceptual overview of a desired future business system.

 Identify areas of concern
      - inspect activities on the BAM
            - operating satisfactory - no immediate action
            - some issues to be addressed - action required
            - not in place - urgent consideration

Framework for the gap analysis

   POPIT (  Processes, Organization, People, Information & Technology

Alignment the proposed actions with the business architecture

McKinsey's 7 S model

   - Systems - which is cover in POPIT and analyzed from 3 views:  process, information, technology
   - Staff and Skills  - are cover in POPIT by people view
   - remains: share values, style, strategy and structure - map  in POPIT on Organization perspective.

Formulating options

  - the key is that the options are holistic. - The best IT systems in the world will not operate effectively if rhe people do not know how to use them or cannot access them.

Defining business requirements

must be at the "what" level rather than dictating the precise ways in which they will be met.

MODELING BUSINESS PROCESSES

Business Processes

A) Begin with a business process map

  -reflect the structure and show set of related processes and their interaction in single diagram
  - Outline process map start with
       -  the core operation at the heart( taking bookings or selling goods)
       -  the processes that provide input to the core process ( making goods, scheduling events)
       -  the processes concerned with delivering products or service to the customer
       -  any sales, marketing or customers service processes.

An alternative to building a process map

 - look at the products and services and consider what processes are required to deliver them.
 - Value chain technique ( Michael Porter)
      - primary activity ( inbound/ outbound logistics, operations, marketing, service ) -> start with operation
      - support activities ( infrastructure, human resource, technology, procurement )

Value propositions -> know what customers want and assure your product is align with these expectations.

- Main Attributes that make up successful value propositions( Kaplan and Norton - 1992)
     - product/service attributes ( functionality - price - quality - choice - availability )
     - Image
     - Relationship
 - An organization can differentiate itself in 3 ways:
     - by being the most efficient
     - by having the best products
     - by providing the best customer service.

-B) Business process model

 - show a detail view of each process
 - is triggered by a business event and includes 5 components : 
      - the tasks that make up the process
      - the process flow
      - the decision points that carry out the tasks
      - the outcome of the business process
 - 3 types of business event: external, internal, time-based

Developing the business Process Model

STANDARDS for modelling business processes:

    a) UML activity diagram technique
    b) business Process Model and Notation ( BPMN)

APPROACH:

Identify actors

  - first talk to an actor, we are interested in:
     - where they get their input info from
     - in general terms, what they do with it
     - where they forward it after they have completed their work

Analyzing tasks

   - each task should be showing as a single action, receiving an input from the preceding actor and handling over to the succeeding actor - this flow of work is know as "hand-offs"
   - task analysis should include:
         - the trigger or business event that initiates the task
         - inputs to the task and outputs to the tasks
         - costs relevant
         - measures and standards applicable to the task
         - detailed breakdown of steps within each task
         - business rules to be followed in performing the task.

Analyzing the "AS IS" process

    - identifying problems
    - analyzing the hand-offs
    - analyzing the processing.
         - Look for: duplication of work, redundancy, lack of standardization, incompleteness, inconsistent measurement or control

Process improvement

 - Review business  rules.  2 categories: constraints and operational guidance
 - Simplify the process
 - Extend the processing
 - Remove bottlenecks
 - Change the sequence of tasks
 - Redefine the process boundary
 - Automate the processing
 - Redesign the process
     -existing process:
      - develop the "as is" model
      - analyze the "as is" process and define its problems
      - identify potential improvements
      - document the "to be" process model
    -new process:
       - define the expected outcomes from the process
       - define the events or triggers that the process will need to react to

Process Measurement

- Performance measures -> understand customers' value expectations
- Performance targets -> have to align with the expectations of the customers
- 2 perspectives on performance measurement:
     - internal measures - the problems is they are focus on what the organization want to achieve and not on what the customer values
      - external measures - what customer will value about the deliverables it receives
            - there are 3 major areas to think about:
                   - the time it takes to complete a process or task
                   - the financial measures (costs & prices)
                   - the quality measures for accuracy and effectiveness

An alternative to process improvement - six sigma

- define the problem
- measure the data
- analyze the data
- analyze the problem
- improve the process by removing the root causes of the problem
- control to prevent the original problem from reoccurring and to maintain the benefits of the changes made

DOCUMENTING & MANAGING REQ.

Structure

```
introduction and background
```

business process models - 'to be' process model set out the vision

function models -show functionality - context & use case diagrams

data model - to understand nature of data and the business rules

requirements catalog: organize req.  using 4 type: business( general and technical) and solution ( functional and non-functional)

glossary of terms - is the key quality for req. doc.

Documenting req.

 - req. identifier T-001, G-006V0-1(draft 1, not agreed), F-028V2-0(second reviewed and agreed version)
 - req. name
 - req. description  -> structure: actor(or user role) verb phrase, object(noun) 
 - source
 - owner
 - author
 - type of requirement ( general, business, functional , non-functional)
 - priority: high, medium, low} or {mandatory, desirable, nice to have} or MoSCoW (must, should, could, want)
 - business area
 - shareholders - details of their interest
 - acceptance criteria
 - related documents
 - comments
 - version history
 - resolution: outcome of the req.

Managing req.

   - traceability of the req. it is a critical quality
   - 2 forms: horizontal and vertical
    - horizontal traceability:  tracing req. from inception to delivery
    - vertical traceability: align with business values, strategy and objectives.
    - components: 
          - req. identification
          - software support
          - req. cross-referencing
          - req. origin and ownership
          - change control
          - configuration manag.: configuration identification  & configuration control( configuration intem - CI). to assure change are traceable.

MAKE A BUSINESS AND FINANCIAL CASE

Create Business Case
a. identify and explore options
-> business activity modelling or business process modeling
b. shortlist options
c. evaluate shortlist
d. take options forward to business case
- Assess solution feasibility

 - business, technical and financial feasibility
 - use PESTLE analysis to assess project feasibility
         (political, economic, socio-cultural, technological, legal, environmental
  - use Force-field analysis : consider those forces inside and outside the organization that will support adoption of the proposal and those that will oppose it

Structure of a business case

   - introduction
   - manag. summary
   - description of the current situation
   - options considered
   - analysis of costs and benefits -> tangible and intangible
   - impact assessment
   - risk assessment  -> description, impact assessment, probability, countermeasures, ownership
   - recommendations
   - appendices, with supporting information.

Financial Case
Investment appraisal

 - the tangible costs and benefits 
 - show if and when the project will pay of for itself.

a) use "payback" calculation

   - is a cash-flow forecast for the project 
   - do not take account of what is call "time value of money" . Means that money spent or saved today is not worth the same as it will be next year or in 5 years. In part this is the part of the inflation. There are other way spending money instead of investing in a project: leave it in the bank to earn interest or borrow money

b) Discounted cash flow (DCF)

   - takes account of the time value of the money
   - leads to a "net present value" NPV for the projects.
          - all of the cash flows in the years after year X are adjusted to today's value of money.
          - use a "discount rate" in calculating discount cash flow.

c) Internal Rate of return ( IRR)

   - assess what sort of return on investment is represented by the project in terms of a single percentage figure
   - compare projects one with another to see which are the better investment opportunities
  - compare what the same money could earn if just left in the bank.
  - it is work out by standing the DCF/NPV calculations on their head
  - at what point would financial costs and benefits precisely balance each other

DCF/NPV is the best method of assessing the value of an investment.
RAID log document

Risk -> probability of occurrence, scale of impact, actions propsed to avoid or mitigate , who should own each risk,

```
Assumptions
```

Issue - some issues are risk which have materialized. Having a junior project team is known form the outset and have 100% probability of occurring.

```
Dependencies
```

CARDI = RAID + constraints

contraints -> those from the "iron triangle" - time, cost(recourses) and product (Quality)

MODELING REQ.

A) Modeling business
-> Use Case Diagram

actors - expect a service from the system

use cases - function that the system will perform in response to a trigger from an actor

```
system boundary
```

associations - integration between actors and use case

<<include/extend>> interaction between use cases

B) Modeling data
-> entity relationship diagram ( attributes, relationships)
-> class diagram (3 sections: name, attributes, methods)

        - associations: connection between classes
        - generalization and inheritance

DELIVERING REQ.

Factors in delivery approach

- context(lifecycle, approach, roles, deliverables)
- techniques

Delivery lifecycle

definition, design, implementation, realization(review benefits), alignment( enterprise architecture, business env., business strategy)

1. System Development approaches

 - ( SDLC - system dev. lifecycles)
 - feasibility study, analysis, design, development, testing, implementation
 - 2 philosophies : linear approach and evolutionary approach

a) waterfall lifecycle( linear approach)
b) "V" model ( linear approach)

     - analyze business needs - business case - review benefits
     - define requirements - acceptance criteria - ensure user acceptance
     - design solution - systems test criteria - test solution
     - develop solution - unit test criteria - test modules

c) Agile model ( iterative approach)

 - principles
      - evolutionary
      - empowerment and collaboration
      - fitness for purpose
      - testing all the time
      - re-factoring
      - incremental delivery 
      - prioritization
      - timeboxing
- Lifecycle
      - identify business need
      - identify options and feasibility
      - define and agree business req.
      - elaborate solution req.
      - engineer solution
      - deploy solution
      - evaluate solution

2. Software development approaches
- Unified Process(UP)

      - generic software development process 
      - provide guide on how to use UML
      - it is both an iterative and incremental approach
      - based on principle to use UML modelling tech. to explore and elaborate req. through iterations
      - agile software dev. approaches include:
             a) DSDM 
             b) Scrum (  keys: Pareto, prioritization- MoSCoW)

- Software pck. approach

       - adopt commercial off-the-self (COTS) solution
       - it is tricky because: req. focus on what the system is required to do, rather than how it is expected to work