Thinking Outside the Requirements Management Box Managing Requirements
Thinking Outside the Requirements Management “Box” Managing Requirements at the Object Level Chicago SPIN February 3, 2000 Larry Boldt SVP, Software Services Technology Builders, Inc. (TBI) larry@tbi. com 770. 937. 7881
Topics v The traditional approach to Requirements Management v The object-oriented approach: Why we need to think outside the Requirements Management “Box” v Getting your organization to think outside the RM “Box”
What is a Requirement? A Requirement may be many things, including: t A statement of the problem t A negotiated win condition t A statement identifying a capability, physical characteristic, or a quality factor that bounds a product or process need of the proposed solution
Requirements Management Involves. . . Planning v Establishing requirement management standards and guidelines Organizing v Staffing projects with personnel who understand are charged with their requirement management responsibilities Directing v Ensuring that program/project managers lead and direct project personnel to follow the requirement management standards and process Controlling v Ensuring that a standard change procedure is established and followed that allows necessary requirement state changes
Key Lifecycle Processes Tests Tasks & Estimates Requirements drive the process Deliverables Components
Who does Requirements Management Today ? Environments 1. Cost of failure is very high or life-threatening 2. Complexity is very high 3. Regulations require extensive documentation 4. Engineering of embedded systems v v v v Industries Military Medical Avionics Telecoms Manufacturing Embedded Systems Financial
Who will do Requirements Management Tomorrow? Trends: 1. …increasing recognition among development teams of the need to mitigate the cost of failing to meet requirements 2. … increasing focus among certain requirements management vendors on understanding the needs of software developers outside of the traditional markets Giga Information Group
Causes of Project/Product Failures #1. Failure to meet project or market requirements #2. Technical complexity #3. Inaccurate budgeting or planning #4. Design/implementation errors Giga Information Group
The Goals of Most Projects 1. On time and within budget ? e c rifi 2. High level of quality 3. Meets requirements i h W u o y e r a e n o h c g n i l l i w c a s to
Requirement Failures Occurred Because. . . 1. Willingness to sacrifice requirements to meet date, cost, and bug counts (lack of commitment) 2. Failure to gather requirements accurately in the first place (lack of a shared form) 3. Software drifted away from meeting requirements during the development process (lack of process)
What the Business Needs. . . What the customer really needs
The Requirements Management Challenge What gets lost in the translation?
The Goal of Requirements Management Common vision among all stakeholders
Traditional Inside the RM “Box” Thinking Informal Process Project Focused Document Creation Translation & Interpretation One-time Usage Manage Documents Limited Change Notification
Why We Need to Change the RM Process “Experiences using Formal Methods for Requirements Modeling. ” Easterbrook, et al.
What the Experts Have to Say. . . “Ever wonder why there are so many buggy e-commerce sites? It’s a sorry tale of web presence over performance. ” “The mad dash to create e-commerce sites is forcing prudent business practices out the window. ” “The trend is how fast can you get the site up, not did you test and test again. That’s why we are seeing a lot of legal disclaimers on the bottoms of sites. ” “It’s the Ready, Shoot, Aim school of development. ”
What if. . . v The requirements specification were treated as a group of integrated, reusable objects instead of a static document? v Requirements could be captured at their source instead of being gathered and translated from one source to another? v Requirements were stored in a central repository where they could be communicated and collaborated on by the entire organization? v All stakeholders were automatically notified any time a requirement changed?
Outside the RM “Box” Thinking Ente Foc rprise use d s d ate r g e Int ge a Man ces o r P ects j b O ity bil a s u Re ent m u Doc eration Gen Informal Process Project focused Document Creation Translation & Interpretation One-time Usage Manage Documents Limited Change Notification Tim e Not ly ifica tion Sou rce Imp a Ana ct lysis Cap ture
Lifecycle of a Requirement Object Requirement Elicitation Requirement Verification Requirement Change Management Requirement Representation Requirement Analysis
Things We Need Answers to. . . Why are we doing this task? What is this component supposed to do? How will we integrate this? When can I expect this functionality? Where is this request being fulfilled?
Lifecycle Process Relationships Requirements Management Process Why? What? How? Identify & Evaluate Needs Derive & Analyze System Requirements Design & Allocate Solutions TIME Who/ When? Project Management Process If - Then Risk Management Process Prove It Test Management Process Manage Change Component & Configuration Management Process
Can Technology Help? How do we record and use requirements today? t Paper t Verbal agreements We could. . . t Use word documents t Build databases - Access, Excel, SQL Server, Oracle The process remains a manual one in all cases!
Minimum Technology Requirements v. Requirements Capture t Descriptive text t Attributes t Reuse t External References v. Requirements Publishing t Individual & Standard reports t Online & batch hardcopy generation t Web publishing v Team/Collaboration Support t Locking/Sharing t Collaboration/Discussion t Version control/Tracking t Baselining v Lifecycle Support t Dependency/Relationship traceability t Lifecycle Integration (test, design & project objects)
Getting Your Organization Out of the “Box” v Who is involved in the requirement management process? v At what phases of the lifecycle do you capture and document requirements? v How and where do you document and maintain your requirements? v How do you manage changes to requirements? v How much time do you spend writing and publishing requirements documents?
What are the Alternatives? v Do Nothing Keep process manual and labor intensive t Use word processing files and E-mail as documentation t Hope nothing in the process breaks! v Do Something t Develop a strategy to improve the process t Automate where we can t Minimize system and user change v Think Outside the “Box” t Develop a new process t Improve cycle times (make it a goal) t Partner with the business (provide 2 -way feedback - goal sharing) t Centralize the dissemination of project related information t
Other Questions We Need to Answer. . . v Why do we need requirements management? v What are the alternatives? v When should requirements management be used? v How can we accomplish this?
Why do We Need Requirements Management? To Visualize the Business v Document agreement of what the business wants to accomplish v Remove ambiguity v Enable the “Big Picture” view of the business To Focus Resources v Right resource/Right application v Manage customer expectations v Control project expense Doing the right things right the first time
When Should Requirements Management be Used? Business v projects needing control over customer-driven agreements v deliverables that customers consider critical IT v all planned, budgeted deliverables v all development and infrastructure projects v for budget planning
How Can We Accomplish This? v Pilot the Process Define the customer organization t Recruit key business executive sponsor t Meet all the requirements and exceed them if possible t v Document the experience v Determine needs and ROI t Cost avoidance for rework & delays
Best Practices v Define requirements as objects v Make individual owners responsible for requirement quality v Encourage buy-in from both IT and Business at all stages…build it in v Derive each successive level of requirements from the previous v Manage change with an iron fist v Conduct requirement ambiguity reviews
Starting Tomorrow. . . Guidelines for Writing Quality Requirements v Write in a style readable by all audiences v Write requirements in a casual language as opposed to a formal language (e. g. , computer language) v Keep sentences and paragraphs short v Avoid ambiguity (multiple meanings/interpretations v Write requirements at a consistent level
Starting Tomorrow. . . Guidelines for Reviewing Requirements v Do you understand the requirement? - Unambiguous - Complete - Testable - Modifiable v Is the requirement valid? - Correct - Necessary - Feasible v Does the set of requirements make sense? - Consistent - Traceable - Prioritized
Avoid Ambiguous Terms v support v large v minimize v intuitive v maximize v robust v optimize v state-of-the-art v rapid v improve v user-friendly v efficient v easy v flexible v simple v and/or v often v etc. v usually
Requirements as objects provides. . . v Visibility clearer elicitation, analysis and communication Reusability t versioning and baselining of requirements within a software project that has multiple releases. Testability t verification and validation on an individual level. Traceability & Replaceability t tracing from inception to deployment. Stakeholders immediately know what components need to be changed or replaced. Maintainability & Security t Each requirement has its own individual change history and level of security. t v v
Thinking Outside the Requirements Management “Box” Managing Requirements at the Object Level Chicago SPIN February 3, 2000 Larry Boldt SVP, Software Services Technology Builders, Inc. (TBI) larry@tbi. com 770. 937. 7881
- Slides: 35