Four principles seminar manageware seminar

1,000 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,000
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Four principles seminar manageware seminar

  1. 1. ® IBM Software Group Ensuring Project Success: Four Principles for Effective Requirements Lifecycle Management Dr. Keith Collyer Requirements Product Delivery Team keith.collyer@uk.ibm.com © 2008 IBM Corporation Although we use screenshots from DOORS to illustrate many of the points in this presentation, DOORS is not the focus.
  2. 2. IBM Software Group | Rational software Our world is becoming more complex everyday... 162 million 90% 1 trillion Almost 162 million smart phones Nearly 90% of innovation Soon, there will be 1 trillion were sold in 2008, surpassing in automobiles is related to connected devices in the world, laptop sales for the first time. software and electronics constituting an “internet of things.” systems.
  3. 3. IBM Software Group | Rational software ...and the challenge of managing this complexity has never been greater 48 months $300 billion 42,000 Five years ago, a typical units recalled manufacturer’s concept- 66% of software products are More than 42,000 defibrillators through production cycle time deemed unsuccessful, costing had to be recalled in 2007 due was 48 months. Within four the industry nearly $300 billion to faulty software. years, that time dropped annually. to 18 months—with a goal of reaching a 12 month cycle within the next year. Development timescales are tighter than ever before, but the regulations and standards developers must meet are more stringent than ever. The cost of failure is increasing at a fantastic rate
  4. 4. IBM Software Group | Rational software 4 Principles for Effective Requirements Lifecycle Management Recognize the needs of all stakeholders N Automate your Use abstraction to requirements process W E manage complexity S Integrate requirements across the lifecycle We could choose many ways of dividing up the topic of requirements management. We will use four main principles as our guide. Recognize the needs of all stakeholders Understand the problem as much as the solution Effective requirements writing and requirement document structure Use abstraction to manage complexity Requirement decomposition and derivation The necessity of traceability Integrate requirements across the lifecycle Requirements are the primary communication tool across the whole development lifecycle RM + Design + Testing + Change + PLM Automate your requirements process Apply measures to facilitate process improvement Use a Requirements Management tool
  5. 5. Principle 1: Recognize the needs of all stakeholders IBM Software Group | Rational software Avoid Premature Details at Top Levels Problem Solution State what the State what the stakeholders system must do: want to be able to Function do: Capabilities We use many conceptual processes in developing systems. We can think of these processes as: Define the problem: Why are we doing this? Define the solution: What do we need to do? Design the solution: How are we going to do it? These processes can occur in parallel, top-down, bottom-up or in a mixed fashion. And one person's solution can become another person's problem, so systems development is generally a recursive process. It is important that the “levels” of development are related – in the sense that the solution developed must solve the problem stated.
  6. 6. Principle 1: Recognize the needs of all stakeholders IBM Software Group | Rational software Avoid Premature Details at Top Levels Problem Solution Do not design Do not define the system the design – avoid How We use many conceptual processes in developing systems. We can think of these processes as: Define the problem: Why are we doing this? Define the solution: What do we need to do? Design the solution: How are we going to do it? These processes can occur in parallel, top-down, bottom-up or in a mixed fashion. And one person's solution can become another person's problem, so systems development is generally a recursive process. It is important that the “levels” of development are related – in the sense that the solution developed must solve the problem stated.
  7. 7. Principle 1: Recognize the needs of all stakeholders IBM Software Group | Rational software An Exercise in clear and concise descriptive writing? The system shall perform at the maximum rating at all times except that in emergencies it shall be capable of providing up to 125% rating unless the emergency condition continues for more than 15 minutes in which case the rating shall be reduced to 105% but in the event that only 95% can be achieved then the system shall activate a reduced rating exception and shall maintain the rating within 10% of the stated values for a minimum of 30 minutes. Don’t attempt to get it right first time – Richard Stevens “if a job’s worth doing, it’s worth doing badly” Clear: each statement is clearly understandable and in the appropriate terminology Consistent: The requirement is consistent with other requirements Abstract: does not impose a solution on the next layer Correct: correctly reflects the intent Individual: each statement is a single traceable element Testable: each requirement has acceptance criteria and can be validated/verified Feasible: each requirement is physically and legally possible Prioritised: each requirement has a priority associated Justified: each requirement has a rationale explaining how it satisfies input needs
  8. 8. Principle 1: Recognize the needs of all stakeholders IBM Software Group | Rational software Document Structure Structure helps: Understand context Assess completeness Identify repetition/conflict Navigate/search requirements Small projects can get away with work-item lists as dealing with a few tens of requirements is within the scope of a human mind. Larger projects need some structure. Structure helps us to: Understand the context of requirements by placing similar requirements together in a hierarchical framework Assess the completeness of the requirements set, for example by using a template and highlighting empty sections Identify repetition/conflict as requirements for similar subjects will be placed close together Navigate/search requirements by providing a decomposition structure which enables successive refinement to find necessary information
  9. 9. Principle 1: Recognize the needs of all stakeholders IBM Software Group | Rational software Structure and Templates Document Structure Boiler-plate text Requirement templates Project templates A template may contain different levels of information: Simple heading structure Boilerplate text that is always similar for every module based on this template Requirement templates to help support good requirement writing practices Project templates combine multiple document templates in a structured fashion, ideally also including definition of allowed relationships
  10. 10. Principle 1: Recognize the needs of all stakeholders IBM Software Group | Rational software Attributes Identification Type Performance Priority Status Attributes are used for several things: Identification: Any form of label, normally an alphanumeric string (for example an object identifier) Classification by type: e.g. functional, non-functional, legal, constraint Classification by priority: e.g. 1,2,3 or high, medium, low Status: e.g. approved, validated, rejected, changed. Status attributes should have a documented state machine Performance: test results, data rates, any numerical data
  11. 11. PrincipleSoftware Group | Rational software manage complexity IBM 2: Use abstraction to Keep information at the right level Look before you leap! General rule: Provide as much information as needed – but no more Avoid design at early stages Be aware of when you are: ► Defining the problem ► Defining the solution It i s n't t Designing the solution solut hat ► i on i they the t's t can' pr ob hat t se lem they e th G.K. can' e Ches t se e terton This relates back to the discussion of problem and solution. It can be very dangerous, and is certainly inefficient and generally over-restrictive, to create solutions when the problem is not understood. Customers often state how they want a problem to be solved, frequently without any clear view of what the problem actually is. The best response to this tendency is to ask “Why?” enough times to get to the real (sometimes called “The 5 Whys”)
  12. 12. PrincipleSoftware Group | Rational software manage complexity IBM 2: Use abstraction to Building a Requirements Hierarchy Decomposition Design-driven •Transformation Allocation Many processes are needed to build up requirements sets Decomposition: Decompose requirements into parts Break compound requirements into atomic statements Design-driven (also called “derived”): Create new requirements to take into account higher-level design decisions For example, the design decision to have a separate Engine and Gearbox leads to the need for those subsystems to interact, and those interactions are defined by requirements Transformation: Turn vague statements into precise statements Turn problem statements into solution statements Turn stakeholder-oriented capabilities into system-oriented functions Allocation: Allocate requirements to subsystems. Often hand-in-hand with decomposition E.g. Allocate “car moves” to engine, drive train, steering, ...
  13. 13. PrincipleSoftware Group | Rational software manage complexity IBM 2: Use abstraction to Why is Traceability Important? Why are we building this? Where is this implemented? How do I test this? Can we show these answers? (Governance) Traceability information lets us answer important questions asked by stakeholders, developers, testers, managers, etc. Necessity: are all the traced lower-level requirements necessary to satisfy the higher- level? Ensure that there is no gold-plating. Why are we building this? Sufficiency: are the traced lower-level requirements sufficient to satisfy the higher-level? Ensure that system developed satisfies requirements. Where is this implemented? Both the above apply to testing as well as to development. How do we test this? Impact: what other changes are contingent on those proposed (up, down and horizontally). Analyze proposed changes. Can we show these answers?
  14. 14. Principle 3: Group | Rational software IBM Software Integrate RM across the lifecycle RM across the Enterprise Corporate Vision Board Portfolio and Program Management Program Managers Project Management, Requirements Project Managers, Analysts and Management Requirements Engineers Requirements Use, Development Tools Developers Different levels in the enterprise use requirements in different ways and hence have different needs for RM. It is important that the corporate vision is reflected through all levels – very few organizations have the understanding, knowledge or tools to do this. The corporate vision is about satisfying stakeholders (typically shareholders) The program portfolio defines what must be achieved to meet the vision and high-level targets such as time and budget. Projects are created to deliver results to the overall portfolio. This is where Requirements Management is traditionally seen to start. The Development organizations consume and produce requirements to actually build systems
  15. 15. Principle 3: Group | Rational software IBM Software Integrate RM across the lifecycle Requirements Definition & Management Must Be Integrated into the Product Lifecycle Define Define Product / Product / Run / Customer Develop Preliminary Detail Operation System System System Support / Disposal Needs Reqt’s Reqt’s Concept Definition Definition Deliver Maintain Build Business Analysis: Enterprise Architecture, Business Process Mgmt, Product Mgmt, Portfolio Mgmt Program & Project Management: Cost Accounting, Scheduling, Measurements, Reporting, Risk Mgmt Requirements Management Detailed Design and Implementation Mechanical Engineering Electronics Engineering Software Engineering Integration Verification and Validation – Test Management Change and Configuration Management The important message here is that development is not done in isolated silos, but by many disciplines working together. The common thread for all this work is requirements. Requirements Management applies to all aspects of development and across the whole product lifecycle, even through to disposal. Requirements are the principle means of communicating between different disciplines and that they are the only technical information that persists throughout the whole life
  16. 16. Principle 3: Group | Rational software IBM Software Integrate RM across the lifecycle Standards Project Constraints Plan Rev B Project Plan Rev A Stakeholder Requirements Test Cases Use Cases Modeling tool Test Results System Test Requirements Cases Test Defects Functional Cases Modeling Models ICD ICD tool ICD Data Synchronized Sub-System Sub-System Sub-System Requirements Requirements Requirements RQM Potentially Potentially to any Module Glossary from any doc CRs Change Design tool This slide shows an example information architecture. We build it up by showing the way requirements flow through levels, then show how additional information is related
  17. 17. Principle 4: Automate your requirements process IBM Software Group | Rational software Measure the requirements process CMMI, ITIL and other process assessment frameworks expect measurement ► CMMI needs RM to get to level 2 ► Need measurement to understand efficiency and consistency ► Key to continuous process improvement "In physical science the first essential step in the direction of learning any subject is to find principles of numerical reckoning and practicable methods for measuring some quality connected with it. I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be." Lord Kelvin, 1893 CMMI & ITIL are assessment frameworks used in industry and IT development
  18. 18. Principle 4: Automate your requirements process IBM Software Group | Rational software Effective Requirements Management realizes quantifiable savings and with a tool you are able to measure Example: how to measure and results Development releases consisting of typically 8000 requirements used to take 6 months Phase 1 - Application of robust process and tool enforcement reduced this period to 12 Weeks over a period of 1 year Phase 2 - Continuous process improvement for a further 12 months reduced this period to 6 weeks Over time, defect removal and effectiveness was 55% at phase 1, 88% at phase 2 and still improving Defects undetected end up with the customer – the figures represent huge improvements in cost of re- work, quality and customer satisfaction
  19. 19. Principle 4: Automate your requirements process IBM Software Group | Rational software Use a Requirements Management Tool Document structure Attributes Filter to focus View related information View historical information Using a requirements management tool gives you many advantages over using standard office applications: Information can be viewed in many ways, including document structure Attributes can be defined to suit the processes in an organization Filters can be used to focus on specific requirements according to user-defined criteria Information can be linked in various ways and related information displayed Historical information is recorded and can be displayed All these different types of information can be displayed at the same time
  20. 20. IBM Software Group | Rational software Benefits of Effective Requirements Lifecycle Management Greater Confidence Ability to manage change Improved customer/supplier relations Visibility of progress/status Improved Cost / Benefit Decisions Greater confidence that objectives are being met. Organizing and tracing requirements engenders greater reflection on the design process and makes the design rationale more explicit. Ability to manage change through impact analysis. Requirements tracing allows the potential impact of changes to be assessed more rapidly. Improved customer / supplier relations through better definition and understanding of contracts, a large part of which are requirements. Ability to track progress / status particularly in the formative stages of a project. When all that the project team is doing is writing documents, it is sometimes hard to measure progress. Effective requirements management puts measurable processes in place. Ability to save costs through cost / benefit analysis. Again, requirements tracing is a way of documenting the relationship between benefits (as expressed by the requirements) and cost (as expressed by the design).
  21. 21. IBM Software Group | Rational software 4 Principles for Effective Requirements Lifecycle Management Recognize the needs of all stakeholders N Automate your Use abstraction to requirements process W E manage complexity S Integrate requirements across the lifecycle We could choose many ways of dividing up the topic of requirements management. We will use four main principles as our guide. Recognize the needs of all stakeholders Understand the problem as much as the solution Effective requirements writing and requirement document structure Use abstraction to manage complexity Requirement decomposition and derivation The necessity of traceability Integrate requirements across the lifecycle Requirements are the primary communication tool across the whole development lifecycle RM + Design + Testing + Change + PLM Automate your requirements process Apply measures to facilitate process improvement Use a Requirements Management tool
  22. 22. ® IBM Software Group Addendum: Avoiding Requirements Writing Pitfalls © 2008 IBM Corporation Using a requirements management tool gives you many advantages over using standard office applications: Information can be viewed in many ways, including document structure Attributes can be defined to suit the processes in an organization Filters can be used to focus on specific requirements according to user-defined criteria Information can be linked in various ways and related information displayed Historical information is recorded and can be displayed All these different types of information can be displayed at the same time
  23. 23. IBM Software Group | Rational software Characteristics of a Good Requirement Design-Free Consistent Traceable Complete Individual Verifiable Identified Feasible Modular Positive Correct Unique Clear Positive Modular Design-Free Traceable Feasible Consistent Clear Verifiable Correct Complete Unique Individual Identified Individual each requirement is a single traceable element Unique each statement is different Identified each statement has a unique reference for identification purposed e.g. “PQR 345” Correct Correctly represents the parent requirement Complete Express a whole idea or statement Clear Unambiguous simple language to avoid confusion and ambiguity Consistent Not in conflict with other requirements Verifiable It can be determined that the system meets the requirement Traceable Uniquely identified and can be tracked and traced Feasible Can be accomplished within cost and schedule Modular Can be changed without excessive impact Positive Written in the affirmative, not the negative Design-Free Does not impose a specific solution on design (i.e., implementation free)
  24. 24. IBM Software Group | Rational software Anatomy of a Good Stakeholder Requirement “The internet user shall be able to access their “The internet user shall be able to access their current account balance in less than 5 seconds.” current account balance in less than 5 seconds.” Measurable (but from when?) Performance criteria Positive end result user type The challenge is to seek out the user type, end result, The challenge is to seek out the user type, end result, and success measure in every requirement you and success measure in every requirement you define. define. r572
  25. 25. IBM Software Group | Rational software Writing Pitfalls to Avoid … or … … etc. … shall include but not be limited to … Example: “The pilot and/or co-pilot shall also be able to hear or see a visible or audible caution/warning signal incase of emergency, hazard, etc…” Improvements: Ambiguity Ambiguity Have individual and specific requirements for the pilot and co-pilot. Create single requirements for visual and audible parts. Be specific on what emergency or hazard conditions will be reported.
  26. 26. IBM Software Group | Rational software Writing Pitfalls to Avoid each requirement is a single sentence conjunctions …and… , …or…. , …with… , …also… Example: “The user shall be notified with a low battery warning lamp light when the voltage drops below 3.6 Volts and the current workspace or input data shall be saved.” Improvements: Multiples Multiples Make separate stakeholder requirements. “The operator shall be visually notified when the voltage drops to a level where work cannot continue.” “The operator shall be able to recover all data after a power failure.” Make separate system requirements: “The system shall provide a low battery warning lamp light when the voltage drops below 3.6 Volts.” “The system shall save the current workspace when the voltage drops below 3.6 Volts.”
  27. 27. IBM Software Group | Rational software Writing Pitfalls to Avoid ‘let out’ clauses …if… , …but… , …when… , …except… …unless… , …although…. Example: “The homeowner shall always hear the smoke detector alarm when smoke is detected unless the alarm is being tested or suppressed.” Improvements: Escape Clauses Escape Clauses ”The homeowner shall hear the alarm when smoke is detected.” “The homeowner shall be able to suppress the sound generated by the fire alarm when the alarm is in ‘Test’ mode.”
  28. 28. IBM Software Group | Rational software Writing Pitfalls to Avoid long sentences arcane language references to unreachable documents Example: “Provided that the designated input signals from the specified devices are received by the user in the correct order where the system is able to differentiate the designators, the output signal shall comply Improvements: with the required framework of section 3.1.5 to indicate the desired input state.” Rambling Rambling “The user shall receive an output signal in compliance section 3.1.5.” “The user shall receive the output signal indicating desired input state.”
  29. 29. IBM Software Group | Rational software Writing Pitfalls to Avoid mix user, system, design, test, installation high level mixed with database design, software terms, technical terms Example: “The user shall be able to view the currently selected channel number which shall be displayed in 14pt Swiss type on an LCD panel tested to Federal Regulation Standard 567-89 and mounted with shockproof rubber Improvements: washers.” Mixing Requirements Mixing Requirements “The user shall be able to view the currently selected channel number.” “The system shall display the selected channels on an LCD Panel.” “The LCD Panel shall be shockproof mounted.” “The LCD Panel shall be tested to Federal Regulation Standard 567- 89”
  30. 30. IBM Software Group | Rational software Writing Pitfalls to Avoid specify design envelope for level required name components, materials, software objects, fields, records in stakeholder or system requirements Example: “The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof hardened rubber shield” Improvements: Designing Designing “The antenna shall be capable of receiving FM signals.”
  31. 31. IBM Software Group | Rational software Writing Pitfalls to Avoid wish lists vague about which stakeholder is speaking …usually… , …generally… , …often… , …normally… , …typically… Example: “The alarm system will probably have to operate over normal phone lines.” Improvements: Speculation Speculation “The alarm system shall operate over the household’s standard telephone line.”
  32. 32. IBM Software Group | Rational software Writing Pitfalls to Avoid qualitative terms user friendly, highly versatile, flexible to the maximum extent, approximately, as much as possible, minimal impact. Example: “The user shall be provided with a user- friendly front-end.” Improvements: Vagueness Vagueness “The user shall be guided through the system with navigation aids and dialog displays.” “The user shall be guided to the next step with labeled instructions.” “The user shall be provided with context sensitive help display.”
  33. 33. IBM Software Group | Rational software Writing Pitfalls to Avoid suggestions will be ignored by developers may, might, should, ought, could, perhaps, probably Example: “The network manager may be provided with possible network contention points and should instantaneously re-route the traffic.” Improvements: Suggestions and Possibilities Suggestions and Possibilities Deliberately use the verbs “shall” or “will” to signal a requirement. Attempt to make each requirement realistic and achievable!
  34. 34. IBM Software Group | Rational software Writing Pitfalls to Avoid ask for the impossible 100% reliable, safe, handle all failures, fully upgradeable, run on all platforms Example: “The network manager shall handle all unexpected errors without crashing the system and be fully capable of managing future network configurations.” Improvements: Wishful Thinking Wishful Thinking It is impossible to handle all unexpected errors! One needs to limit and enumerate the requirement to known error types. There is no way to predict future network configurations much less manage them.
  35. 35. IBM Software Group | Rational software Optional “Questions” Breaker Slide
  36. 36. IBM Software Group | Rational software © Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

×