Requirements Analysis

6.0 Overview

  • Analyze stated requirements in order to define the required capabilities of a potential solution that will fulfill stakeholder needs
  • Apply to both stakeholder and solution requirements
  • Develop models of the current state of an organization
  • Useful for validating the solution scope with business and technical stakeholders

6.1 Prioritize Requirements

  • Purpose
    • Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements
  • Description
    • Determine the relative importance of requirements
    • Based on relative value, risk, difficulty of implementation
    • Used to determine which requirements should be targets for further analysis and to determine which requirements should be implemented first
  • Input
    • Business Case – states the key goals
    • Business Need – alternative to the business case
    • Requirements – may be prioritized
    • Requirements Management Plan – defines the process
    • Stakeholder List, Roles, and Responsibilities
  • Elements
    1. Basis for Prioritization
      • Business Value – cost-benefit analysis
      • Business or Technical Risk – highest risk of project failure
      • Implementation Difficulty – easiest to implement
      • Likelihood of Success – relatively certain successes
      • Regulatory or Policy Compliance – meet regulatory or policy
      • Relationship to Other Requirements – support other REQ
      • Stakeholder Agreement – consensus
      • Urgency – time sensitivity
    2. Challenges
      • Non-negotiable Demands – desire to rank all requirements
      • Unrealistic Tradeoffs – influence on prioritization process by overestimating the difficulty or complexity of implementing
  • Techniques
    1. General
    2. MoSCoW
      • Must / Should / Could / Won’t
    3. Timeboxing/Budgeting
      • Based on allocation of a fixed resource
      • All In – Remove the REQ to meet the calendar or budget limit
      • All Out – Stop when the calendar are met or budget is reached
      • Selective – Identifying high priority, add or remove REQ
    4. Voting
      • Allocate a fixed amount of resources to each participant for them to distribute among proposed features or requirements
  • Stakeholders
    • Domain SME – to assess the relative business need
    • Implementation SME – evaluate the relative complexity
    • Project Manager – input into the project plan
    • Sponsor – participate in the discussion
  • Output
    • Requirements [Prioritized] – A prioritized requirement has an attribute that describes its relative importance to stakeholders and the organization. At the completion of this task, each requirement should have an assigned priority. The priorities may apply to a requirement or to a group or related requirements.

6.2 Organize Requirements

  • Purpose
    • To create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives
  • Description
    • Understand which models are appropriate for the business domain and solution scope
    • Identify model interrelationships and dependencies
  • Input
    • Organizational Process Assets – structures and types
    • Requirements [Stated] – must be analyzed to ensure that they reflect a genuine need
    • Solution Scope – needed perspectives
  • Elements
    • Following guidelines :
      • Follow organizational standards or select an appropriate set of techniques
      • Use simple, consistent definitions, business terminology
      • Document dependencies and interrelationships
      • Produce a consistent set of models and templates
    • Levels of Abstraction
      • Distinguish between what and how
      • Informally designate a set of REQ as “high” or “low” level
    • Model Selection
      • Determine which types of models will be required
      • Models abstract and simplify reality
      • Models do not have any inherent hierarchy
      • General modeling concepts
        • User Classes, Profiles, or Roles – directly interact with a solution
        • Concepts and Relationships – relevant to the business domain
        • Events – trigger or affect a business process
        • Processes – who and what has to be involved
        • Rules – enforce goals and guide decision-making
  • Techniques
  • Stakeholders
    • Domain SME, End User, Implementation SME, and Sponsor
    • Project Manager – verify the scope of the solution
  • Output
    • Requirements Structure – documented set of relationships

6.3 Specify and Model Requirements

  • Purpose
    • To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models
  • Description
    • Created to analyze the functioning of an organization and provide insight into opportunities for improvement
    • Facilitate communication among stakeholders
    • Supporte training activities and knowledge management
  • Input
    • Requirements [Stated] – structure and improve understanding of needs as expressed by stakeholders
    • Requirements Structure – Defines how the requirement fits into the general requirements
  • Elements
    1. Text – describe the capabilities of the solution, conditions and constraints. Guidelines are:
      • Express one and only one requirement at a time
      • Avoid complex conditional clauses
      • Use terminology that is consistent
      • Express requirements as a verb or verb phrase
    2. Matrix Documentation – convey a set of REQ that have a complex but uniform structure which can be broken down into elements:
      • Attributes and data dictionaries are often expressed in tabular form
      • Used for traceability of requirements
      • Used for prioritizing requirements
    3. Models
      • Modeling Formats – simplified representation of a complex reality, textual and/or graphical, they can:
        • Describe a situation or define a problem
        • Show business logic
      • Notations – Describe any symbol or notation used
      • Formal versus Informal Models:
        • A formal model follows semantics and iconography, defined in a standard
        • An informal model does not have a formal semantic definition, no special training to interpret
    4. Capture Requirements Attributes – While specifing and modeling the relevant attributes must be captured
    5. Improvement Opportunities – improve the operation of the business, like:
      • Automate Or Simplify The Work People Perform
      • Improve Access To Information
      • Reduce Complexity Of Interfaces
      • Increase Consistency Of Behavior
      • Eliminate Redundancy
  • Tecnhiques
  • Stakeholders
    • Any Stakeholder
  • Output
    • Requirements [Analyzed] – Modeled and specified requirements are produced by this task

6.4 Define Assumptions and Constraints

  • Purpose
    • Identify factors other than requirements that may affect which solutions are viable
  • Description
    • Assumptions are factors that are believed to be true, but have not been confirmed
    • Constraints are defined as restrictions or limitations on possible solutions
    • Both are generally documented with associated attributes
  • Input
    • Stakeholder Concerns – Assumptions and constraints are identified through elicitation from stakeholders
  • Elements
    1. Assumptions – relate to something in the present or in the future, need to be documented
    2. Business Constraints – may reflect budgetary restrictions, time restrictions, examined to ensure that they are accurate and justified
    3. Technical Constraints – architecture decisions that may impact the design of the solution, may include development languages, hardware and software platforms, any enterprise architecture standards that must be followed
  • Techniques
    • Problem Tracking – ongoing planning, monitoring, and issue/risk management
    • Risk Analysis – if an assumption proves invalid, or a constraint is removed
  • Stakeholders
    • All Stakeholders – should be involved in any discussion that involves changing
  • Output
    • Assumptions and Constraints – will limit potential solution options, can be managed and communicated

6.5 Verify Requirements

  • Purpose
    • Ensures that REQ specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work
  • Description
    • Ensures that the REQ have been defined correctly, that they are of acceptable quality, constitutes a final check to determine that the requirements are:
      • ready for formal review and validation
      • provide all the information needed
  • Input
    • Requirements [Any Except Stated] – Verification is a quality check performed following analysis of a requirement
  • Elements
    1. Characteristics of Requirements Quality
      • Cohesive – relates to only one thing
      • Complete – all relevant requirements
      • Consistent – do not contradict each other
      • Correct – Defects will lead to defects in the resulting solution
      • Feasible – implementable within the existing infrastructure
      • Modifiable – exhibited by a logical structuring
      • Unambiguous – never be unclear
      • Testable – prove that a requirement has been fulfilled
    2. Verification Activities – performed iteratively throughout the requirements analysis process. Include:
      • Check for completeness
      • Compare each prepared requirements model
      • Make sure all variations to the documented processes have been identified and documented
      • Make sure all triggers and outcomes have been accounted
      • Make sure the terminology used is understandable
      • Add examples where appropriate
  • Techniques
    1. General
    2. Checklists
      • Quality control technique for requirements documentation
      • Include a standard set of quality elements
      • Ensure that items that the organization or project team has determined are important are included in the final requirements deliverable
      • Developed on a project basis to help ensure consistency of approach and outcomes
  • Stakeholders
    • All of them – may discover problematic requirements during requirements communication
  • Output
    • Requirements [Verified] – Verified requirements are of sufficient quality to allow further work based on those requirements to be performed

6.6 Validate Requirements

  • Purpose
    • Ensure that all REQ support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need
  • Description
    • An ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements
    • Stakeholders will have different, conflicting needs and expectations that may be exposed through the validation process and will need to be reconciled
  • Input
    • Business Case – describes the overall business objectives
    • Stakeholder, Solution, or Transition Requirements [Verified] – need to be verified for validation to be completed
  • Elements
    1. Identify Assumptions
    2. Define Measurable Evaluation Criteria
    3. Determine Business Value
    4. Determine Dependencies for Benefits Realization
    5. Evaluate Alignment with Business Case and Opportunity Cost
  • Techniques
  • Stakeholders
    • All of them
  • Output
    • Requirements [Validated] – those that can be demonstrated to deliver value to stakeholders and are aligned with the business goals and objectives
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s