|
As the pace of high-tech development increases and development cycle times decrease, the life cycle of a product or system is constantly bombarded with a furious, unrelenting onslaught of change. From the first "back of the envelope" vision until the day the product or system is retired, the influence of changing markets, customer expectations, and technology creates a constantly moving target for product requirements and the resulting design. During a development project's execution, as the project team tries to shrink the delta between requirements and the emerging design, change becomes an opposing force, altering the requirements target and widening the delta. In "Requirements and Change Management", we focus on managing these two forces to achieve a successful project closure on an evolving and dynamically changing set of requirements. During product development, we are faced with a continuous battery of change requests. How do you dynamically manage change during all phases of a project? How does requirements management need to evolve in this volatile environment where the phrase "freezing the requirements" has little meaning? How do you manage the constant flurry of issues that occur as change pressure is applied to requirements? How can you prepare for and manage staff, management, customer, and stakeholder frustrations? How do you "thrive on change" in the physical world of printed circuit boards, complex software code, and packaging molds and tools? This is the place to watch as our community builds knowledge, know-how, and tools to deal with managing change.
- TEMPLATE:
The SWOT Analysis template contains a review of Strengths, Weaknesses, Opportunities, and Threats affecting the subject of the analysis. SWOT analysis is often used to evaluate strategic choices (project objectives, priorities, etc.) and can also be used to review potential impacts on things like a process, solution, or business entity.
- GUIDELINE:
A requirements workshop requires planning and preparation, along with good meeting facilitation skills. The most successful requirements workshops are well planned: they include clear and deliberate opening and closing activities; they include carefully selected exercises, discussions, and activities to elicit and model the requirements; and they are facilitated with the right balance of flexibility and diligence. The Requirements Workshop Planning Guide provides tips to help you think through these important aspects of a requirements workshop.
- GUIDELINE:
Business rules are an important part of the requirements package, but they're challenging to write, manage, and maintain without a rules repository. The Business Rules Management Guideline is designed to help you develop your own approach, by providing some basic guidance on business rules and tips for rules organization, management, and change control. Effectively stating, organizing, and managing business rules will help ensure that they can be appropriately applied to the end solution.
- GUIDELINE:
Whether it's launching a new project or discovering how well the current solution is meeting expectations, you need to know how to get there from here. A Gap Analysis will help you figure out where there is, where here is, and how best to bridge any gaps between them.
- TEMPLATE:
Requirements are the backbone of the project, and how effectively they are managed can make or break a project. A Requirements Management Plan captures the tools the team will use to record and track requirements, reinforces the importance of traceability, and articulates the project's risk management and change control strategies.
- TEMPLATE:
A requirements walkthrough is a focused meeting where requirements documents are reviewed in order to finalize or baseline the requirements before they are handed off to the development team. The Requirements Walkthrough Checklist will ensure you have considered and accounted for the key components of a successful requirements walkthrough meeting.
- TEMPLATE:
A requirements interview is a focused interview with a key stakeholder or subject matter expert designed to elicit a specific set of requirements. The Requirements Interview Checklist is organized into sets of questions you should consider for each interview; important preparation that will increase your credibility and help you make the most of your time with these key resources.
- TEMPLATE:
A Root Cause Analysis Checklist is designed to help you methodically identify the root cause of a given problem or issue, by asking a series of questions, and by considering the problem from different angles. It allows you to challenge first-reaction thinking, and to consider issues and problems in light of current business realities.
- TEMPLATE:
Business process models can help companies with process improvement, capturing requirements, automation, compliance, training, and more. The Business Process Modeling Technique Brief provides basic guidance on how to conduct a modeling effort, commonly used approaches, and how to avoid typical problems.
- TEMPLATE:
A Business Data Dictionary Template organizes and defines all the data elements relevant to a particular software system, and includes additional information that helps establish a common understanding of the nature of the data element.
- TEMPLATE:
Agile methodologies like Scrum and Extreme Programming (XP) often build on "user stories" as a way of capturing and tracking feature requirements. The Agile Technique – Requirements Cards brief explains how to use the technique—referred to here as requirements cards in order to widen the horizon to customers and stakeholders.
- TEMPLATE:
Streamline the provider selection process using this template for a Training Program Request for Proposal (RFP). A comprehensive RFP will help you gain clarity and alignment on the real goals of your training program, and will make sifting through offerings and choosing an appropriate vendor easier on your selection committee.
- TEMPLATE:
Our New System Request for Proposal (RFP) Outline provides a comprehensive RFP template for new systems proposal requests, along with guidelines for RFP success and detailed annotations. Customize this template to fit your software system or co-development project and shave weeks off your RFP selection time.
- CASE STUDY:
Requirements management doesn't have to break the bank, or the back. Veteran software executive Anita Wotiz outlines the alternatives in a case study, "Software Requirements Management - Not Just for Big Companies."
- GUIDELINE:
Not sure whether to cancel the project, or how? Check out our Project Cancellation Guidelines for a comprehensive guideline to help you make the decision, and an extensive checklist of considerations if you do decide cancellation is the best alternative.
- PAPER:
If you're wondering how to make sure only the best and brightest project ideas get approved (and eliminate the "projects materializing out of thin air" phenomenon), check out this book excerpt on the Product Planning Process. It's applicable in general to the approval and orderly launching of any new project. This excerpt covers documenting new project ideas, refining them, how to run an approval process, what a Marketing Requirements Document should contain and how long it should be, and details on how to run a product planning meeting to review, approve (or not) and officially launch new projects.
- PAPER:
"Transferring a Genetically Engineered Biopharmaceutical from Research to Clinical Development - Impact on Facility Design and Build Projects" (offsite link) This paper from Pharmaceutical Engineering uses the transfer of a product from R&D into Phase 1 clinical trials to discuss how time-to-market concerns often drive design of manufacturing facilities before the manufacturing process has been full designed. Changes during technology transfer of those processes to manufacturing will then impact the facility-related projects, and this case study covers approaches to facility design and build projects that can be used to handle the uncertainty and risks.
- TEMPLATE:
A Statement of Work provides one approach to documenting high-level project objectives and key parameters in a concise document. Helps make sure the team and all stakeholders understand agree upon the reasons for doing the project, what the project will produce, and various important constraints and assumptions. Such a document should be done before detailed requirements specs are written.
- TEMPLATE:
Our Business Requirements Document is a detailed, annotated outline provides a solid foundation for expressing the true requirements of the project—as well as the business case and context—so the development team knows what to go code before they start.
- TEMPLATE:
Our Marketing Requirements Document is created by a Marketing or Business group or other representatives of "customers" and "users" to express the perceived customer wants and needs for product, system, or service. A good MRD ensures that the project is driven by true customer needs and a sound business proposition. Primary audience for the document is the project team, and specifically the functional groups which must determine how to implement the product, system, or service to meet those requirements.
- TEMPLATE:
The Software Requirements Specification (SRS) provides a document format for a particular module or subsystem of software. Based on an IEEE standard for SRSs, it contains not only sections for software functionality, but also sections for important software attributes and interface definitions. It also contains an overview section that summarizes important items about the software in a way that is especially effective for non-Development project stakeholders.
- TEMPLATE:
Our annotated outline for a Product Requirements Specification, should be used early in a project to define what a product will be designed to do, in response to requests from customers and Marketing. It ensures that the team has understood and responded thoroughly to the product requests put forward by Marketing, with the PRS documenting the detailed requirements that "made the cut." The PRS will be used to drive lower level design work, plan related development activities, and support meaningful estimates of effort, risk, etc. to implement what Marketing is asking for.
- TEMPLATE:
Our Change Control Form may be used to request and document changes to the project, for instance the addition of certain features, or elements within the project, such as changing a major spec of a piece of a system, product, or other project deliverable. Contains fields for impact of the proposed change on the project timeline, budget etc., and on the components of the project deliverables. The goal is to ensure that the impact of any change is well understood, carefully considered, and consciously approved, rather than executed as adhoc changes that could jeopardize the project's success.
- PAPER:
Our paper on managing the endgame of a project contains insights into issue and change management.
- ARTICLE:
The Software Testing & Quality Engineering journal often has articles in the area of requirements management for software projects.
- ADDITIONAL RESOURCES:
If you're wondering how to document the requirements for your user interface effectively, here are some resources:
- Among our archived Columns with a Requirements & Change Management theme:
- Our book list contains some good references on this subject.
|
Return to Top