1 / 25

Lost In Translation: When Great Requirements Lead to Not-so-great Products

Lost In Translation: When Great Requirements Lead to Not-so-great Products. David Altman 404.771.2569 rqmd@adelphia.net.  2005 RqMD. Presentation Disclaimers/Caveats There is no one best way. I’ll only provide information about things that I’ve personally

amory
Télécharger la présentation

Lost In Translation: When Great Requirements Lead to Not-so-great Products

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lost In Translation: When Great Requirements Lead to Not-so-great Products David Altman 404.771.2569 rqmd@adelphia.net 2005 RqMD

  2. Presentation Disclaimers/Caveats • There is no one best way. • I’ll only provide information about things that I’ve personally • experienced or proven to work. • Tonight’s subject matter is NOT specific to • software/web development. • Please, let’s not let semantics get in the way.

  3. Requirements Management (RQM) is: • All activities within the product development lifecycle that are associated with the • Elicitation • Analysis/Triage • Documentation/Dissemination • Change Control, and • Verification/Validation • of customer, business, and stakeholder requirements.

  4. The Value of RQM If done well, RQM serves to ensure that everyone involved in the product development lifecycle has a verifiable, clear, sustained, and ultimately confirmed vision of what the business, stakeholders, and users need in-and-from the product.

  5. Where does RQM fit in?

  6. Reality Check.. • Product development time without RQM: • 17% spent on requirements definition / plan 33% designing solution 50% re-design • Product development time with RQM: • 66% spent on requirements definition/plan/methods 24% designing solution 10% redesign

  7. The Facts: • Design rework can consume as much as 40% of total development costs • 70-80% of revisions can be attributed to requirements definition errors (Leffingwell 1997) • Correcting a requirements error after product launch costs 68 times as much as correcting a requirement during requirements definition (Boehm 1981) • In a study of 8380 projects, the top two reasons that projects failed were lack of user input and incomplete requirements definition (Sandish 1995)

  8. Problem Space • Nonexistent/limited elicitation capability • Insufficient elicitation depth/rigor • Inability to gain stakeholder cooperation/effort • Inability to baseline requirements/false baseline • Inability to hear/manage change “noise” • Mixing technology and product development • Non-existent/weak verification/validation

  9. Solution Space

  10. Create an Elicitation Plan • The Elicitation Plan describes: • Key elicitation targets (see next slide) • Value of target to requirements • Relative effort required to address each target • Relative risk to product/project if the target is not addressed • The Elicitation Plan is submitted to, and approved by, a Business level Stakeholder.

  11. Build the PDL-RQM Relationship • Your Software Development Lifecycle (SDLC)/Product Development Lifecycle (PDL) is the environment in which RQM practices live. • If your SDLC/PDL is not healthy, your RQM practices will not be effective. • The SDLC/PDL must designate at what point (phase) in the lifecycle the requirements are baselined (frozen) and become subject to formal change management.

  12. Establish the PRD as a Contract • Cultural acceptance of the PRD as a contract between the business and the stakeholders • Only one official (on-line) copy of the PRD • PRD contains detailed change history log • Requirement attributes designate source, ownership, and verification method

  13. Use a Requirements Champion • Requirements management is not a skill set, it’s an occupation. You can’t delegate it. • If you don’t have an experience Requirements Analyst, hire one. • Someone (the RA) must be tuned in to collect change ‘noise.’ • Elicitation is an art. Surveys are a tool.

  14. Train..and then train some more • It’s not easy to train some people to change their paradigm from “How” to “What” • Requirements management is rarely effective it is pushed. It must be pulled. • Train management first; they’re the biggest violator. • Emphasize ‘Big boy rules’

  15. Use Risk Management • Unless you have a limitless budget and timeline, it is unlikely that all possible requirements can be met. • Use a requirements risk attribute to focus the effort. • It’s futile to identify a risky requirement without identifying how you want to reduce/eliminate the risk. • Manage risk using a Feasibility Plan • High risk requirements map to the Feasibility Plan • The plan identifies what the risk is and how/when during the project the risk will be managed.

  16. Big Boy Rules • The PRD is a contract; treat it like one • Honor your role in the process. The verification knife cuts both way. • Management: Walk the talk. • The truth isn’t always glamorous or easy. Maintain requirements discipline.

  17. Post Mortems • The PRD change history log is an excellent source of objective evidence as to the success or failure of the RQM process. • At the end of every project, the requirements analyst briefs executive management about the successes and failures of the RQM process, and about what can be improved for the next project (lessons learned). • Someone (read: the Requirements Analyst) briefs the project team about lessons learned before each new project.

More Related