Requirements elicitation


Published on

Simple steps for eliciting requirements

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Here are some example of capabilities. They appear obvious. But in many instances this approach is missing. The requirements are the starting point for the solution. In the absence of the capabilities statement and the Concept of Operations the user community may have trouble envisioning how the system will benefit them when it becomes available.The tendency to start with the requirements should be avoided. Requirements need a home, a reason for being.These examples are from actual projects. They represent clear and concise statement about the need for the system, the use of the system for the business or mission purpose, and how the end user will benefit from the system.
  • Poorly formed requirements have been shown to contribute as much as 25% to the failure modes of programs and projects.Requirements engineering can be decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. The Performance Based Management(sm)method concentrates instead on elicitation. This method addresses problems found with requirements engineering that are not adequately addressed by specification techniques.This Performance Based Management(sm) method incorporates advantages of existing elicitation techniques while addressing the activities performed during requirements elicitation. These activities include fact–finding, requirements gathering, evaluation and rationalization, prioritization, and integration.
  • The first step is to separate “product” requirements from “process” requirements. The product could be a service as well, but the product (or service) is not the same as the process that delivers the service that may be enabled by the product.We can see there are several components of this separation. Later on in this session we’ll put this taxonomy to use with a process for requirements management. While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity, focus our efforts on important the parts of requirements management, and reduce the overall effort of managing these requirements.
  • Requirements elicitation

    1. 1. Increasing the Maturity of Project Work Chapter 0 Processes and Their Deliverables 1 Identify Indentify Establish Execute Needed Baseline Performance Performance Capabilities Requirements Measurement Measurement Baseline Baseline Perform Continuous Risk Management (CRM)  Define Capabilities  Fact Finding  Decompose Scope  Perform Work  Define ConOps  Gather And Classify  Assign Accountability  Accumulate  Assess Needs, Cost, and  Evaluate And  Arrange Work Performance Measures Risk Impacts Rationalize  Develop BCWS  Analyze Performance  Define Balanced and  Prioritize Requirements  Assign Performance  Take Corrective Action Feasible Alternatives  Integrate And Validate Define the Measurable Assure All Requirements Define Measures of Ensure Cost, Schedule, Capabilities of each Provided In Support of Performance and and Technical Project Outcome Capabilities Effectiveness Performance CompliancePerformance Based Management(sm), Copyright ® Glen B. Alleman, 2012
    2. 2.  Define the capabilities needed to achieve the desired objectives or a particular end state for a specific scenario. Define the details of who, where, and how these capabilities are to be accomplished, employed, and executed.1.1  Partition system capabilities into classes of service within operational scenarios.  Connect the capabilities to system requirements using some visual modeling notation.  Define Measures of Effectiveness (MoE) and Measures of Performance (MoP).  Define the delivery schedule for each measure of performance and effectiveness.1.2  Define scenarios for each system capability.  Connect these scenarios to a Value Stream Map of the increasing maturity of the program.  Assess value flow through the map for each needed capability.  Identify capability mismatches and make corrections to improve overall value flow.1.3  Assign costs to each system element using a value flow model.  Assure risk, probabilistic cost and benefit performance attributes are defined.  Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance.1.4  Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts.  Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs. 2 Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012 Chapter 0
    3. 3. Chapter 0 What Does A Capability “Sound” Like? 3Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
    4. 4. Chapter 0 Identifying Needed System Capabilities 4 What Should We Do? Where Are We Now? Abstracted from: “Capabilities‒Based Planning – How It Is Intended To Work And Challenges To Its Successful Implementation,” Col. Stephen K. Walker, United States Army, U. S. Army War College, March 2005Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
    5. 5.  Define the technical and operational requirements that must be present for the system capabilities to be delivered. Define these requirements in terms isolated from any technology or implementation. Assure each requirement is connected to a need system capability.2.1  Produce an overall statement of the problem in the operational context.  Develop the overall operational and technical objectives of the target system.  Defined the boundaries and interfaces of the target system.2.2  Gather required system capabilities, functional, nonfunctional and environmental requirements, and design constraints.  Build the Top Down capabilities and functional decomposition of the requirements in a Requirements Management System.2.3  Answer the question “why do I need this?” in terms of operational capabilities.  Build a cost / benefit model using probabilistic assessment of all variables, their dependencies, and impacts.  For all requirements, perform a risk assessment to cost and schedule.2.4  Determine criticality for the functions of the system.  Determine trade off relationships for all requirements to be used when option decisions must be made.  For all technical items, prioritize their cost and dependency.2.5  Address the completeness of requirements by removing all “TBD” items.  Validate that the requirements are traceable to system capabilities, goals, and mission.  Resolve any requirements inconsistencies and conflicts.5 Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012 Chapter 0
    6. 6. Chapter 0 What Is a Requirement? 6Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
    7. 7. Chapter 0 Identifying Requirements† 7 †Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.