Business Requirement & Feasibility Analysis - KU-SKE17/Software-Process GitHub Wiki

Table of Contents

Requirement Development & Management

  • To get the requirement, talk to the right people (Requirement Providers)
  • Requirement Providers and Requirement Receivers make an agreement
  • Providers change request -> a set of approved requirement

Requirement: Traditional vs Agile

  • Traditional
    • Sequential Project Development
    • complete requirements
  • Agile
    • Scrum Project
    • just enough and just in time for sprint

Requirement Practice (CMMI)

  • 5 steps (RDM)
    1. Understand Requirements
    2. Obtain Commitment to Requirements
    3. Manage Requirements
    4. Maintain Bidirectional Traceability of Requirements
    5. Ensure Alignment between Project Work and Requirements

RDM 1: Understand Requirements

  • ask who are we going to talk
  • Establish criteria -> appropriate requirements providers
    • Clear
    • Complete
    • Consistent(not conflict)
    • Verifiable(testable)
    • Achievable(implementable)
    • Validity(reflect client intentions)
    • Stability
  • Establish objective criteria -> acceptance of requirements (validation)

Output -> A set of approved requirements

  • Agile: Product Backlog
    • Replacement for the requirements of a traditional project
    • User Activities -> User Stories
    • System Features
  • User Stories
    • Title
    • Priority
    • Estimate
    • User Story
      • As a [user role],
      • I want [functionality]
      • so that [benefit]
    • Acceptance Criteria
      • Given [how things begin]
      • When [action taken]
      • Then [outcome of taking action]
  • Agile: Feasibility Analysis
    • INVEST in a good quality of User Story
    • Independent == Complete
    • Negotiable != Stability
    • Valuable == Validity
    • Estimable == Clear
    • Sized Appropriately / Small == Achievable
    • Testable == Verifiable
    • Not Consistent!
  • Use Cases (Use-case Diagram)
    • Use Case
    • Actor
    • Communication Link

RDM 2: Obtain Commitment to Requirements

  • Assess the impact of requirements on existing commitments Negotiate
  • Record commitments

Output -> Commitment Documents

  • requirements
  • requirement changes

RDM 3: Manage Requirements

  • Document all requirements and requirements changes that are given to or generated by the project
  • Maintain a requirement change history, including the rationale for changes
  • Evaluate the impact of requirement changes from the standpoint of relevant stakeholders
  • Make requirements and change data available to the project

Output -> Requirement List

  • Req. ID
  • Req. Name
  • Req. Detail
  • Req. From
  • Req. Date
  • Req. Priority
    • Priority: MoSCoW Prioritization
      • Must Have –> Minimum Usable SubseT which the project guarantees to deliver
      • Should Have –> Important but not vital / May be painful to leave out but the solution still viable
      • Could Have –> Wanted or desirable but less important
      • Would Have -> Won’t Have this time, maybe in the future
  • Req. Status
    • Product Backlog Status
      • To Do
      • In-Progress
      • Testing
      • Done

RDM 4: Maintain Bidirectional Traceability of Requirements

  • To ensure that the source of lower-level requirements is documented
  • Maintain requirements traceability from a requirement to its derived requirements and allocation to work products
  • Generate a requirements traceability matrix

Output -> Requirement Traceability Matrix: RTM

RDM 5: Ensure Alignment between Project Work and Requirements

  • Review project plans, activities, and work products for consistency with requirements and changes made to them.
  • Identify the source of the inconsistency
  • Identify any changes that should be made to plans and work products resulting from changes to the requirements baseline
  • Initiate any necessary corrective actions

Output -> Inconsistency Corrective Actions

Product Architecture

for E-Commerce web site

  • Part1: Web front-end
  • Part2: Checkout service
  • Part3: Marketing & Recommendations

Product Architecture will depend on WBS

Work Breakdown Structure

  • WBS (work breakdown structure)
  • Method to make complex projects more manageable (breaking down a project into tasks and subtasks)
  • so that there is no room for confusion in the future.
  • Feature Slicing