Inception is Not the Requirements Phase

  • Inceptions - The initial short step to establish a common vision and basic scope for the project

  • Inception includes: analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirements (quality attributes), creation of a business case, preparation of the development environment

  • Questions to explore: What is the vision and business case for this project?, Is it feasible?, Buy and/or build?, Rough estimate of cost?, Should we proceed or stop?

  • Do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system

  • Decide if it’s worthwhile to invest in deeper exploration

  • Most requirements analysis occurs during elaboration.

  • Inception - Envision the product scope, vision, and business case.

  • Main problem solved - Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?

  • Optional artifacts in Inception: Vision and business case, Use case model, Supplementary specification, Glossary, Risk list & risk management plan, Prototypes and proof of-concepts, Iteration plan, Phase plan & software development plan, Development case

  • Inception is more than “a few” weeks long for most projects

  • There is an attempt to define most of the requirements

  • Estimates or plans are expected to be reliable

  • You define the architecture - this should be done iteratively in elaboration

  • You believe the proper sequence of work should be: define the requirements, design the architecture, implement

  • There is no business case or vision artifact

  • All the use cases are written in detail

  • None of the use cases are written in detail - 10-20% should be written in detail to obtain some realistic insight into the scope of the problem

  • UML in Inception: not much diagramming is warranted, Simple UML use case diagrams may be useful, Most UML diagramming occurs in elaboration…

  • Managing the requirements is not fully defining and stabilizing them before beginning design and coding

  • Given the reality of unclear, changing requirements (volatility)… 

  • Managing requirements is … a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

  • The single largest contributing factor to failure: cited in 82% of projects as the number one problem (Thomas 2001), requirements definition is a cause of failure in nearly 80% of failed projects (Taylor 2000)

  • Any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed.

  • 45% of waterfall-style requirements were never used (Johnson 2002), 19% were “rarely” used 

  • FURPS+ - requirement categories in the UP

  • FURPS+: functional, usability, reliability, performance, supportability + implementation, interface, operations, packaging, legal

  • Functional - features, capabilities, security

  • Usability - human factors, help, documentation

  • Reliability - frequency of failure, recoverability, predictability

  • Performance - response times, throughput, accuracy, availability, resource usage

  • Supportability - adaptability, maintainability, internationalization, configurability

  • implementation - resource limitations, languages and tools, hardware

  • interface - constraints imposed by interfacing with external systems

  • operations - system management in its operational setting

  • packaging - for example, a physical box

  • legal - licensing and so forth

  • Quality attributes - The “-ilities” of a system drive the architectural decisions…

  • In common use, requirements are categorized into: functional requirements (behavioral), non-functional requirements (everything else)

  • UP Requirements Artifacts: Use case model, supplementary specification, glossary, vision, business rules

  • Use case model - typical scenarios of using a system, primarily for functional requirements

  • Supplementary specification - non-functional requirements, features not expressible as use cases

  • Glossary - noteworthy terms, data dictionary

  • Vision - executive overview of the project’s big ideas

  • Business rules - domain rules, transcend a single project