Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

The Myth Of Requirements

The myths of requirements are that:

• Requirements gathered from business users through requirements gathering meetings and workshops define the scope and functionality of the solution
• Requirements gathering workshops at the start of a project are sufficient to understand business needs
• Requirements change

The reality is that what is gathered during requirements workshops, meetings, interviews, questionnaires and other activities are not solution requirements but business stakeholder requirements.

Stakeholder requirements must be translated into solution requirements which is turn must be translated into a solution design. A solution is a Resolver, a Provider or an Enabler.

Good solution design requires solution ownership and technical leadership throughout the process.

Any solution is always greater than the sum of the gather requirements. Requirements do not equal a solution.

Any solution also causes problems in terms of:

• Required organisational changes to implement and operate solution
• Additional operational overhead
• Cost to implement

The solution is the minimum set of components that works and that solves the problem at the minimum cost with minimum additional costs.

  • Soyez le premier à commenter

The Myth Of Requirements

  1. 1. The Myth Of Requirements Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney
  2. 2. Myth Of Requirements • Myth is that requirements gathered from business users and business stakeholders through requirements gathering meetings and workshops define the scope and functionality of the solution • Myth is that in order to define the solution, all that is needed is business requirements Requirements ≠Solution Solution ≠Requirements Solution is always >>ΣRequirements January 5, 2016 2
  3. 3. Requirements Gathering Exercises • It is unreasonable to expect that business stakeholders in a potential solution can articulate a set of complete, fully- developed consistent requirements through part-time involvement in a few requirements gathering exercises • This process always causes problems • So who do project managers do this time and time again? January 5, 2016 3
  4. 4. Need For Solution Exists Because … • I have a problem • I want to be able to do what I am currently unable to do • I cannot do what I want • I need to be able to do something • A solution is a Resolver, a Provider or an Enabler January 5, 2016 4
  5. 5. Any Complete Solution Consists of: • Zero or more of {Changes to Existing Systems} • + Zero or more of {New Custom Developed Applications} • + Zero or more of {Information Storage Facilities} • + Zero or more of {Acquired and Customised Software Products} • + Zero or more of {System Integrations/Data Transfers/Exchanges} • + Zero or more of {Changes to Existing Business Processes} • + Zero or more of {New Business Processes} • + Zero or more of {Organisational Changes} • + Zero or more of {Reporting and Analysis Facilities} • + Zero or more of {Existing Data Conversions/Migrations} • + Zero or more of {New Data Loads} • + Zero or more of {Training and Documentation} • + Zero or more of {Central, Distributed and Communications Infrastructure} • + Zero or more of {Sets of Installation and Implementation Services} • + Zero or more of {Cutover/Transfer to Production} • + Zero or more of {Operational Functions and Processes} • + Zero or more of {Parallel Runs} January 5, 2016 5
  6. 6. Scope Of Complete Solution January 5, 2016 6 Acquired and Customised Software ProductsChanges to Existing Systems New Custom Developed Applications Information Storage Facilities System Integrations/Data Transfers/Exchanges Changes to Existing Business Processes Organisational Changes Existing Data Conversions/ Migrations New Data Loads Training and Documentation Central, Distributed and Communications Infrastructure Sets of Installation and Implementation Services Cutover/Transfer to Production Operational Functions and Processes Parallel Runs New Business Processes Reporting and Analysis Facilities
  7. 7. Complete Solution • Ignoring some of the components of a complete solution will not make them go away or reduce their need • Complete solution view allows expectations to be managed • Requirements never capture the detail of the complete solution • Requirements are just one set of constraints imposed on the solution design • You will just end-up with apparent project changes as the need for ignored components become actual • Requirements are not delivered – it is the solution and its components that are delivered January 5, 2016 7
  8. 8. Myth Of Changing Requirements • It is not requirements that change • It is that latent requirements were not identified or were ignored that become apparent or unavoidable during implementation • Undiscovered and unarticulated requirements then impact other solution components leading to additional downstream changes which affects the implementation project January 5, 2016 8
  9. 9. A Solution … • Solves a problem or provides new functionality or enables a new or changed way of operating • Any solution also causes problems in terms of: − Required organisational changes to implement and operate solution − Additional operational overhead − Cost to implement • The solution value equation must be: January 5, 2016 9 ΣValue of Problem(s) Solved and Value Delivered >> ΣCost of Problem(s) Caused + ΣCost of Solution Components
  10. 10. Solution Is: • What has to be done • What costs time and money • The minimum set of components that works and that solves the problem at the minimum cost with minimum additional costs • Need to maximise solution efficiency and minimise direct and indirect solution cost January 5, 2016 10
  11. 11. Solution Is About Value Obtained January 5, 2016 11 Minimise Cost Maximise Value Point of Best Value
  12. 12. Requirements Tend To Be: • Sparse and disconnected • Isolated and disintegrated statements • Inconsistent • Incomplete • Disjointed • Conflicting • Uncosted • Unprioritised • Representations of specific points of functionality that do not aggregate into a defined solution • A source of additional unstated and implied requirements January 5, 2016 12
  13. 13. Requirements • The reality is that what is gathered during requirements workshops, meetings, interviews, questionnaires and other activities are not solution requirements but business stakeholder requirements • Stakeholder requirements must be translated into solution requirements which is turn must be translated into a solution design • Requirements gathering is a means to an end and not an end in itself • Requirements gathering should never be part of the delivery project but be the subject of an analysis and architecture design exercise prior to any delivery project • You cannot know what the scope of the project is until the solution that needs to be delivered is known • Never let a project manager near requirements January 5, 2016 13
  14. 14. Requirements Standards – Core • IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications Superseded by • ISO/IEC/IEEE 29148:2011 Systems and Software Engineering – Life Cycle Processes – Requirements Engineering January 5, 2016 14
  15. 15. ISO/IEC/IEEE 29148:2011 Systems and Software Engineering – Life Cycle Processes – Requirements Engineering • Proposes five key deliverables 1. Stakeholder Requirements Specification (StRS) Document 2. System Requirements Specification (SyRS) Document 3. Software Requirements Specification (SRS) Document 4. System Operational Concept (OpsCon) Document 5. Concept of Operations (ConOps) Document • Very detailed and comprehensive and time-consuming to produce • Level of detail appropriate to large software product solutions − Not really applicable to other solutions • Not necessarily possible to create these deliverables at the requirements gathering phase − Substantial design effort required to create these deliverables January 5, 2016 15
  16. 16. ISO/IEC/IEEE 29148:2011 – Stakeholder Requirements Specification (StRS) Document Scope • Business Purpose • Business Scope • Business Overview • Stakeholders • Business Environment • Goal And Objective • Business Model • Information Environment • Business Processes • Business Operational Policies And Rules • Business Operational Constraints • Business Operation Modes • Business Operational Quality • Business Structure • User Requirements • Operational Concept − Operational Policies And Constraints − Description Of The Proposed System − Modes Of System Operation − User Classes And Other Involved Personnel − Support Environment • Operational Scenarios • Project Constraints January 5, 2016 16
  17. 17. ISO/IEC/IEEE 29148:2011 – System Requirements Specification (SyRS) Document Scope • System Purpose • System Scope • System Overview − System Context − System Functions − User Characteristics • Functional Requirements • Usability Requirements • Performance Requirements • System Interfaces • System Operations − Human System Integration Requirements − Maintainability − Reliability • System Modes And States • Physical Characteristics − Physical Requirements − Adaptability Requirements • Environmental Conditions • System Security • Information Management • Policies And Regulations • System Life Cycle Sustainment • Packaging, Handling, Shipping And Transportation • Verification • Assumptions And Dependencies January 5, 2016 17
  18. 18. ISO/IEC/IEEE 29148:2011 – Software Requirements Specification (SRS) Document Scope • Purpose • Scope • Product Perspective − System Interfaces − User Interfaces − Hardware Interfaces − Software Interfaces − Communications Interfaces − Memory Constraints − Operations − Site Adaptation Requirements • Product Functions • Product Functions • Product Functions • Assumptions And Dependencies • Apportioning Of Requirements • Specific Requirements • External Interfaces • Functions • Usability Requirements • Performance Requirements • Logical Database Requirements • Design Constraints • Standards Compliance • Software System Attributes • Verification • Supporting Information January 5, 2016 18
  19. 19. ISO/IEC/IEEE 29148:2011 – System Operational Concept (OpsCon) Document Scope • Scope − Scope − Document Overview − System Overview • Referenced Documents • Current System Or Situation − Background, Objectives, And Scope − Operational Policies And Constraints − Description Of The Current System Or Situation − Modes Of Operation For The Current System Or Situation − User Classes And Other Involved Personnel • Organisational Structure • Profiles Of User Classes • Interactions Among User Classes • Other Involved Personnel − Support Environment • Justification For And Nature Of Changes − Justification For Changes − Description Of Desired Changes − Priorities Among Changes − Changes Considered But Not Included − Assumptions And Constraints • Concepts For The Proposed System − Background, Objectives, And Scope − Operational Policies And Constraints − Description Of The Proposed System − Modes Of Operation − User Classes And Other Involved Personnel • Organisational Structure • Profiles Of User Classes • Interactions Among User Classes • Other Involved Personnel − Support Environment • Operational Scenarios • Summary Of Impacts − Operational Impacts − Organisational Impacts − Impacts During Development • Analysis Of The Proposed System − Benefits − Disadvantages And Limitations − Alternatives Considered January 5, 2016 19
  20. 20. ISO/IEC/IEEE 29148:2011 – Concept of Operations (ConOps) Document Scope • Purpose • Scope • Strategic Plan • Effectiveness • Overall Operation − Context − Systems − Organisational Unit • Governance − Governance Policies − Organisation − Investment Plan − Information Asset Management − Security − Business Continuity Plan − Compliance January 5, 2016 20
  21. 21. Extended Requirements Standards And Linkages January 5, 2016 21 ISO/IEC TR 24766:2010 Information Technology — Systems And Software Engineering — Guide For Requirements Engineering Tool Capabilities ISO/IEC/IEEE 24765:2010 Systems And Software Engineering — Vocabulary IEEE 1220 (ISO/IEC 26702) Systems Engineering — Application And Management Of The Systems Engineering Process ISO/IEC/IEEE 15288:2002 Systems And Software Engineering — System Life Cycle Processes ISO/IEC 25010:2011 Systems And Software Engineering — Systems And Software Quality Requirements And Evaluation (SQuaRE) — System And Software Quality Models ISO/IEC/IEEE 12207:2008 Systems And Software Engineering — Software Life Cycle Processes ISO/IEC 25030:2007 Software Engineering — Software Product Quality Requirements And Evaluation (SQuaRE) — Quality Requirements ISO/IEC/IEEE 29148:2011 Systems And Software Engineering — Life Cycle Processes — Requirements Engineering Co-Ordinated With Refers To Co-Ordinated With Used With Used With Extends Co-Ordinated With Uses Elements Of Co-Ordinated With Co- Ordinated With
  22. 22. Requirements Standards • Complicated set of standards that are rarely, if ever, applied to in-house projects − Tend to be used for product development, if at all • Difficult to apply and use without substantial overhead − Suited only to large developments and large organisations • Standards are quite generic and need to be customised to the needs of the development • Standards are very focused on software product requirements and associated developments and do not cover wider solution requirements • Processes contained in the standards lack the customer interaction dimension • Need a more balanced, realistic and achievable approach to linking requirements to solution design January 5, 2016 22
  23. 23. Requirements And Overall Solution January 5, 2016 23 = Specific Requirement = Solution Factor Not Explicitly Listed As Requirement
  24. 24. Business Stakeholder Requirements And Solution Requirements – Example January 5, 2016 24 How will intervals be named? What naming standards, if any, will apply? What approval workflow will apply to the creation of new intervals? Who will have the right to define and approve and make changes to trading intervals? Sample Business Stakeholder Requirement: In the customer energy trading portal, there shall be a facility to define intervals (for which the customer will be able to fix or unfix previously fixed energy prices at the currently available price) for individual months, quarters of a year, halves of a year, summer and winter seasons and full years for a specified period into the future. How will the specified period in the future be defined and maintained? When an interval has passed, will it be retained? If so, for how long? Will customers see only intervals in the future? What will happen previously defined intervals in this specified future period is changed so those intervals are now partially or completely outside the period? What will happen customer trades made for those intervals? What record is made of changes? How long is this record retained? What interval definition and maintenance facility is required? Should there be a bulk change/upload facility? How should it operate? What functionality should it have? How secure should it be? Who should have access to it? What is the expected volume of changes? How frequently will intervals change?
  25. 25. Business Stakeholder Requirements And Solution Requirements • Single business stakeholder requirements statement will contain a large number of implied solution requirements January 5, 2016 25
  26. 26. Business Stakeholders • These are the business users at all levels in the organisation who will interact or causes users to interact with the solution or have a direct interest in the solution January 5, 2016 26
  27. 27. Characteristics Of A Solution January 5, 2016 27 What It Does, How It Operates – the Functionality Cost/Time/Risk To Implement The “xAbles”
  28. 28. Solution “xAbles” • Usable • Affordable • Deliverable • Operable • Supportable • Maintainable • Flexible • Adaptable • Capable • Scalable • Reliable • Securable • Available • These are very important operational requirements that may not be articulated by business users and stakeholders • They are essential to the success of the solution and its enduring operation and use January 5, 2016 28
  29. 29. Getting The Solution xAbles Right January 5, 2016 29
  30. 30. Getting The Solution xAbles Wrong January 5, 2016 30
  31. 31. Requirements And Standard V Lifecycle Approach January 5, 2016 31 Project Initiation Project Closure System Requirements System Testing High-Level Design Integration Testing Low-Level Design Component Testing Install and Implement
  32. 32. Requirements And Standard V Lifecycle Approach • Simplistic view of solution testing • You do not test requirements – you test the functionality of the overall solution and its ability to deliver on the business processes • Requirements testing will omit significant elements of overall solution functionality • You also need to validate the solution xAbles January 5, 2016 32
  33. 33. Solution Design Process January 5, 2016 33 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Elicit Stakeholder Requirements Formalise Stakeholder Requirements Define Solution Requirements Analyse Solution Requirements Define Solution Architecture and Design Analyse, Evaluate and Refine Solution Architecture Implementation Project Initial Architecture Review and Options
  34. 34. Solution Design Process • Each stage uses the output from the previous stage as an input • Detail is refined, extended and elaborated on in successive stages January 5, 2016 34 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
  35. 35. Solution Design Process Stage Scope Initial Concept Of Need/ Goal/ Objective The business have an idea for a solution based on an apparent need to solve a problem, to do what is currently not possible, to react or respond to an external demand or to be able to achieve a new objective. Formal Statement Of Need/ Goal/ Objective This formalises the initial concept to introduce greater consistency and detail. It serves to understand the business, objectives, purposes and potential organisational impacts. It describes what the ideal solution will do. It also identifies the high-level potential system impacts. Initial Architecture Review and Options This uses the formal statement of need to create an initial high-level view of the overall solution, its new and existing systems and applications components, the required functionality, their interfaces, the required processes and the business functions impacted. This provides a container for the requirements and a vision for the solution. Stakeholder Requirements Collection and Specification This uses this initial architectural review output in a structured way to elicit and formalise the set of stakeholder requirements across the dimensions of functionality and processes. Solution Requirements Collection and Specification The solution requirements specification is a fuller, more detailed and elaborated set of solution requirements encompassing all the solution components. This includes the requirements explicitly identified by stakeholders and the implied requirements. Solution Architecture Design and Specification This is the detailed solution specification derived from the stakeholder and solution requirements. Implementation Project This uses the detailed solution specification to act as an input to project definition and to create a realistic implementation plan, schedule, set of costs and required resources. January 5, 2016 35
  36. 36. Solution Design Process • There is a decision point after each stage where a decision is made if it is worthwhile to proceed to the next stage January 5, 2016 36 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options Decision Points
  37. 37. Solution Design Process • Not all concepts make it all the way to implementation • Process needs to accommodate this • Do as little as possible to achieve as much as possible to make an informed decision on whether and how to proceed to the next stage in the solution journey January 5, 2016 37 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
  38. 38. Solution Design Process - Iterations • Solution design process is not necessarily linear • Stages can be iterated a number of times to different levels of detail January 5, 2016 38 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
  39. 39. Solution Design Process • Business stakeholder requirements are just one input into a fully developed solution design • Taking this approach means the solution implementability, operability, usability, maintainability and supportability can be quantified in advance • It is only after the solution design is defined and agreed that the implementation project can be started January 5, 2016 39
  40. 40. Analysis And Architecture In Solution Design • Analysis is used to gather information and requirements • Analysis does not solve problems or deliver solutions • Analysis is an important step in solution design • Analysis interfaces between the business and IT • Structured approach to gathering requirements in the context of indicative solution architecture yields greater results • Analysis and architecture translates business stakeholder requirements into solution requirements • Architecture synthesises and actualises overall solution design and options from requirements and other constraints January 5, 2016 40
  41. 41. Architecture Options And Structured Business Stakeholder Requirements • Initial solution view comprising processes, functionality, actors and changes to existing applications and new applications will provide a framework and a structured approach for gathering and organising business stakeholder requirements January 5, 2016 41
  42. 42. Architecture Options And Structured Business Stakeholder Requirements January 5, 2016 42
  43. 43. Architecture Options And Structured Business Stakeholder Requirements January 5, 2016 43 Use this architecture component view to define required functionality
  44. 44. Architecture Options And Structured Business Stakeholder Requirements • Initial architecture view provides a scaffold to support individual requirements • Requirements can be drawn-out by identifying their place in the overall solution and flow • Requirements then exist within the context of an overall solution journey and the business processes being enabled by the solution January 5, 2016 44
  45. 45. Solution Delivery January 5, 2016 45 Business Stakeholders Solution Architecture IT Operations Solution Design Process Solution Design Process Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options Analysis
  46. 46. Following A Solution Design Process • Following a solution design process needs solution leadership and ownership • Lack of solution leadership/solution design authority can cause subsequent implementation project to take short- cuts or ignore key solution elements • Solution design must be subject to reviews to ensure that it consists of the minimum set of components that works and that solves the problem at the minimum cost with minimum additional costs January 5, 2016 46
  47. 47. Solution Design Process Attempts To Solve The All Too Common Problems Of … • Lack of response to business needs • Slow and costly solution delivery • High solution maintenance and operation costs • Fragile solutions with many manual workarounds • Excessive and duplicated development effort and operation • Duplicated and costly investments in many solutions • Siloed applications with lack of integration • Poor return on investment • Too little, too late, not what is wanted or needed January 5, 2016 47
  48. 48. Business Stakeholder Requirements – Scope • Business Solution − Solution purpose and objectives − Organisation and business environment − Organisation and business model • Business Operational and Usage Requirements − Solution components and their requirements − Business functions − Business processes − Information model − Organisation structure − Actors − Component interfaces • Solution Concept − Operational scenarios − Solution operation and use January 5, 2016 48
  49. 49. Solution Requirements – Scope • Solution − Scope, purpose − Solution components and interactions − Solution characteristics • Solution Requirements − Solution components and their functionality and requirements − Solution components and overall solution operation and use − Solution processes − Information model − Solution component interactions and information exchanges − Security architecture − Solution components and overall non-functional requirements − Roles and responsibilities − Solution options − Solution packaging January 5, 2016 49
  50. 50. Summary • Myth of requirements is that: − Requirements gathered from business users through requirements gathering meetings and workshops define the scope and functionality of the solution − Requirements gathering workshops at the start of a project are sufficient to understand business needs − Requirements change • The solution is always greater than the sum of the articulated business stakeholder requirements • Good solution design requires solution ownership and technical leadership from the start and throughout the process • Solutions cause as well as fix problems that need to be factored into the process • Requirements do not belong in the context of a project • Never let a project manager near requirements January 5, 2016 50
  51. 51. More Information Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney 05 January 2016 51

×