The document discusses various techniques for managing the scope of a software project, including defining the system scope, establishing a requirements baseline, prioritizing requirements and use cases, and managing stakeholder expectations. It emphasizes the importance of scope management in selecting requirements for each development iteration and controlling what features and functions will be included in the project. It also outlines the roles of a requirements manager and product champion in helping to define and maintain an appropriate project scope.
1. System Scope Management Mastering Requirements Management Flat-World IT Consulting By Christian D. Kobsa Senior Consultant Flat-World IT Consulting A Use-Case Based View
2.
3. Where Are We? Analyze the Problem Understand Stakeholder Needs Define the System Manage System Scope Refine System Definition Manage Requirements Change New System Existing System New Input Incorrect Problem Correct Problem Out of Scope In Scope Flat-World IT Consulting Flat-World IT Consulting
4.
5. Scope Management Capture Problem System to build Test User Doc Problem Space Solution Space Traceability Customer Development Team Flat-World IT Consulting Flat-World IT Consulting Needs Features Software Requirements Design
6. Define System Scope Flat-World IT Consulting Flat-World IT Consulting Scope Time Budget Resources
7.
8. Uses for Requirements Attributes Attributes link project elements Flat-World IT Consulting Flat-World IT Consulting Status Risk Priority Effort Cost Feature 10 Approved Low High High High Feature 13 Proposed Medium Low Low Medium Feature 40 Approved High High High Low
9. Use Cases: Iterative Approach Flat-World IT Consulting Flat-World IT Consulting Use Case A Use Case B Use Case B Use Case A Use Case B Use Case C [scenario 1: main flow] [scenario 2: main flow, alt flow] [scenario 1: main flow] [scenario 2: main flow, alt flow 1] [remaining scenarios and flows] [scenario 3: main flow, alt flow 2] [all scenarios and flows] Iteration n Iteration n + 1 Iteration n + 2
10.
11.
12. Process Helps Manage Scope Single Channel for Approval Approved Decision Process Change Control Board (CCB) Flat-World IT Consulting Flat-World IT Consulting
13.
14.
15.
16.
Notas do Editor
Scope management means setting boundaries for each iteration. This maintains a “healthy tension” between what the customer wants (maximum number of features) and what development can deliver within a fixed timeframe. This is best done through iterative development. It allows to reassess priorities at the end of each iteration.
Here the focus is on setting the baseline scope for the system under development. The best time to decide on the features is AFTER the system is defined, but BEFORE much time is invested into refining details. Beware of wasting time refining systems parts outside the scope of the current system under development. NOTE that this diagram shows only ONE iteration of the process, NOT the entire requirements management lifecycle.
Project scope should be managed continuously. However it is easier to make educated decisions AFTER actors, use cases, supplementary specifications are identified. The system analyst applies customer priority, effort, cost, risk values, and other requirements attributes to more accurately rank development priorities. This allows to identify architecturally significant use cases. The iteration plan is developed in parallel by the project manager. It defines the number and frequency of iterations planned for the release. The scope of the project defined in Managing Scope has significant impact on the Iteration Plan . That is because the highest risk elements within scope are planned for early iterations. Other important output from Managing Scope is: Revised vision document. This is necessary, because the system’s analyst and key stakeholder’s understanding of the system functionality and project resources has been refined.
In order to properly manage scope it is essential that the development team has agreement from the customer regarding the baseline set of features to develop. This is best accomplished through iterative development; developing and delivering slices of the pie. At the end of each iteration, priorities can be reassessed. To avoid scope creep but allow change, consider the following: Real requirements: identify what is really needed from the business objective. Minimum requirements: make it a conscious effort to develop the minimum set of requirements; no “gold plating”! Record all requirements; identify them by source. Have an agreed upon negotiation and sanctioning process. All requirements must come through a well-defined channel; no ambiguous sources…. Manage expectation and communicate with the customer about what will be in each iteration. uncover hidden requirements assumed by the domain experienced customer.
How do you take a fixed amount of resources and choose the best value to produce for the customer? The scope of a project is defined by the set of requirements allocated to it. Managing project scope to fit the available resources (time, people, and money) is key to managing successful projects. NOTE that managing scope is an continuous activity . It requires iterative (incremental) development. This breaks project scope into smaller , more manageable pieces .
How do we know what the needs are? How do we determine priority? How do we reach agreement on what features should be included in the project? Where do we set the baseline commitment for delivery? The key is to under-promise and over-deliver; but not to much! We want to maintain our credibility!!! What stakeholder needs do the features represent? What factors influence the order in which features should be ranked?
Once the baseline scope list of features is set, the features have to be allocated to iterations so they can be implemented in a manner that removes project risk, delivering important functionality as early as possible. Attributes play a key role in the decision making process. Requirements attributes are the link between requirements and other project elements. “Status” provides the current status of each requirement; “effort” estimates the work involved to do each requirement, etc. The uses for requirements attributes are: Managing project scope Assigning resources Scheduling Assessing status Calculating software metrics Managing project risk Estimating cost Assuring user safety Attributes can be specified for all types of requirements: needs, features, use cases, supplementary requirements. The attributes to collect at each level are based on what information is needed for management reports and other users.
When detailing flows in an iteration, detail them so that each flow forms part of a complete story (scenario) that can be implemented and tested . Hence, based on selected scenarios for a given iteration, elaborate the flows that are part of specific scenarios. These are then used for implementation and testing. A given use case is typically NOT completely written and implemented in a single iteration. Rather, each iteration focuses on a subset of the use case scenarios . The scope of the iteration is driven by the following factors: The top risks to the project The functionality required of the system The time allocated to the iteration The phase and its specific objectives The more architecturally important scenarios get addressed in the early iterations.
It is very important to establish a sound architecture in the early iterations. This provides a solid foundation for the rest of the project. That is why, use-case scenarios of architectural importance are done first. How is architectural importance determined? Look for flows that describe the most architecturally significant functionality and map those flows to one or more scenarios. Those use case scenarios are assigned to the first architectural iteration. As the project moves from phase to phase (Inception, Elaboration, Construction, Transition) the criteria for prioritizing use cases changes. During Elaboration select use cases or scenarios to mitigate the technical aspects as quickly as possible. During Construction select use cases or scenarios to deliver essential functionality before non-essential functionality (80:20 rule).
Prioritize use cases (or scenarios) based on high priority features that trace to different flows. Get the 20 percent of functionality that solves 80 percent of the stakeholders needs, and implement these as soon as possible. By definition, these 20 percent are usually the highest priority requirements. NOTE: system analyst are not concerned with the technicalities of implementing a use case. That is the concern of the architect.
To successfully manage scope, an effective change management process MUST be in place. During the software development life cycle, request are received. They MUST be intercepted and MUST pass through a single approval process. If not, there will be scope creep and chaos!!! Through interception and a single approval process requests can be assessed according to criteria such as: origin, customer priority, support of business goals, schedule impact, etc. NOTE that if there is a CCB it should have representatives from each of the relevant groups.
One of the keys to have a happy customer at delivery time, is to manage his expectations of what he will receive.
Communication is VERY important! Make sure there are no surprises. Keep the possibilities open.
Negotiation skills are key to any successful, multi-party program. It is a professional activity and skill that everyone should strive to improve upon. See “Getting to Yes” by Fisher and Ury. The concept of BATNA looks at the consequences of NOT getting to an agreement. How important is that? What if the customer cancels the project? This provides a bottom line to work from. The key is to focus on the interests of all involved and attempt to come up with creative options that satisfy both sides.
This is a very important – often intangible – aspect of having an successful project. Most often it’s not a job title, but a role played by a key individual. Based on research by the Standish Group a staunch product champion, with a solid business vision, often prevents a project from drifting into a technical and/or political abyss. Ask yourself whether you want the product champion on the technical side or the customer side?
![Course Objective ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Flat-World IT Consulting Flat-World IT Consulting](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)