Download presentation
Presentation is loading. Please wait.
Published byBlaze Rose Modified over 9 years ago
1
1 Project localization and identification Define localization Define Internal & External needs Make certain the Project Is Based on Clear Needs Specify What the Project Should Accomplish Specify project Requirements: Problems & Guidelines
2
2 Project must be Based on a Clear Needs The Needs Life Cycle (evolution of needs): Emergence phase (external/internal: business reengineering) Recognition phase (forecasting/scenario building), Articulation phase (direct identification, multidimensional view, research, precise formulation, revise formulation),
3
3 Defining Needs (pitfalls) Misunderstood Needs: ”I’m not sure what I want, but I’ll know it when I see it” (case p. 120). Customers often do not have a precise idea of what they want Addressing the Needs of Customers Sort Out the Needs of Multiple Customers Multiple Customers, Multiple Needs Establish Priorities: The Needs Hierarchy Distort “Father-knows-best-syndrome” Changing needs: changing players, budgets, technology or business environment. Fuzzy Needs: Dynamic & gradually take shape and substance..
4
4 Problems when Specifying Requirements Incorrect Requirements: Imprecise and Ambiguous Requirements: Language, Imprecision for flexibility, Conflict preventing, Abstractions, Lack of Expertise, Oversights on the part of project planners Shifting Requirements: Oversimplification of Requirements: Insufficient information, Initiative discouraged, Requirements ignored, Costly rework efforts Excessive Flexibility: Patchwork deliverables, Chaotic project planning, Time and cost overruns
5
5 Specify What the Project Should accomplish The Nature of Requirements (function/technical) Functional requirements: the characteristics of the deliverable, Technical requirements: written for the technical staff
6
6 Guidelines for Specifying Project Requirements Rule 1: State the requirement explicitly and have project staff and customers sign off on it Rule 2: Be realistic; assume that if a requirement can be misinterpreted, it will be misinterpreted Rule 3: Be realistic; recognize that there will be changes on your project and that things will not go precisely as anticipated Rule 4: To as great an extent as possible, include pictures, graphs, physical models, and other nonverbal exhibits in the formulation of requirements
7
7 Guidelines cont… Rule 5: Establish a system to monitor changes made to the requirements: configuration management: date of change, name of the person requesting change, description of change, statement of the change’s impact on the project, listing of tasks and staff affected by the change, estimate of the cost of the change, signature of the individual making the change request, indicating that this individual is aware of the cost and performance impacts of the requested change Rule 6: Educate project staff and customers to the problem of specifying requirements Application prototyping
8
8
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.