Requirements Engineering Framework

Requirements Engineering Framework

1. Requirements Documentation

   • The method to document requirements
   • Hierarchy of Requirements
     • Solution Requirements
       • Functional
         • Users Doing
         • Data Transations
           • CRUD
             • Create
             • Read
             • Update
             • Delete
           • Procedures
       • Non-Functional
         • System Performance & how it behaves
         • Uncovering Techniques
           • Top Down
             • 'What constraints apply to this area?'
           • Bottom Up
             • 'Is this subject to specific constraints?'
       • Project Specific
     • Business Requirements
       • General Requirements
         • Rules of Operation that apply to all projects
           • Eg. GDPR
       • Technical Requirements
         • Software
         • Hardware
         • Interface
         • Internet

2. Requirements Management

   • Covers Change Management, version & configuration management
   • Traceability
     • Vertical
       • Relationship between requirement and business objective
     • Horizontal
       • Forwards to the end solution
       • Backwards to the original requirement
   • Configuration Management
     • Ensures everyone is working from the same version
   • Change Management
     • Documenting proposed change
     • Analysing impact
       • Time needed
       • Cost
     • Consulting Stakeholders
     • Make Decision
       • Accept Change
       • Reject Change

3. Requirements Elicitation

   • Drawing out requirements from various stakeholders
   • Knowledge Types
     • Unconscious Competence
       • 4 Stages
         • Unconscious incompetence
           • Driving: Child
         • Conscious incompetence
           • Driving: Teen
         • Conscious Competence
           • Driving: Just Passed!
         • Unconscious competence
           • Driving: Years of Experience
     • Tacit Knowledge
       • Knowledge that is Unconscious Competence
         • Done naturally, like skills developed over time
           • May be missed in requirements
     • Tacit vs Explicit
       • Tacit is 'taken for granted' and not often mentioned
         • Explicit is clearly described / defined
   • Elicitation Techniques
     • Interviews, Workshops, Observation, Shadowing, Storytelling,Scenario Analysis, Role Play, Prototyping, Document analysis

4. Requirements Analysis

   • Shape the requirements into a suitable form which are clear & understandable
   • Prioritsation
     • Using MoSCoW
       • Must have
         • Critical for Day 1
       • Should have
         • Critical but not for Day 1
       • Could have
         • Nice to have if time & budget allow
       • Won't have (this time)
         • Not required to meet project objectives (at this stage)
   • Filters
     • Remove the 'rubbish' from requirements
   • User Stories
     • Should cover INVEST
       • Independent
       • Negotiable
       • Valuable
       • Estimate-able
       • Small
       • Testable
   • Slicing Requirments
     • Cutting requirements into slices to deliver to time, based on order

5. Requirements Validation

   • The process to sign off a set of requirements as accurate to what is required
   • Waterfall Projects
     • Single review session at the end of the Design phase
       • No clear opportunity to go back and 'iterate' requirements
   • Agile Projects
     • Requirements are reviewed at the project initiation
       • To ensure alignment to business objectives and establish the 'Backlog'
         • And then brought out of the backlog in iterations to develop, reviewed at each stage