The Requirement Continuum by Stewart Mednick President Emeritus IIBA Minneapolis St. Paul Chapter

Requirement Continuum An iterative requirement lifecycle Functional Decomposition Process Flow Feature Acceptance Criteria Acceptance Criteria User Story Acceptance Criteria User Story Acceptance Criteria Acceptance Criteria User Story Acceptance Criteria

Are you a hedgehog or a fox? The Hedgehog Concept Are you a hedgehog or a fox? In his famous essay “The Hedgehog and the Fox,” Isaiah Berlin divided the world into hedgehogs and foxes, based upon an ancient Greek parable: “The fox knows many things, but the hedgehog knows one big thing.” 

The Hedgehog Concept is developed in the Jim Collins’ book “Good to Great.” A simple, crystalline concept that flows from deep understanding about the intersection of three circles: what you are deeply passionate about, what you can be the best in the world at, and what best drives your economic or resource engine.

with a Hedgehog Concept: Transformations from good to great come about by a series of good decisions made consistently; supremely well executed, accumulating one upon another over a long period of time.

“All good-to-great leaders, it turns out, are hedgehogs. Collins defines the Hedgehog Concept as such: “All good-to-great leaders, it turns out, are hedgehogs. They know how to simplify a complex world into a single, organizing idea — the kind of basic principle that unifies, organizes, and guides all decisions….

Collins defines the Hedgehog Concept as such: …That’s not to say hedgehogs are simplistic. Like great thinkers, who take complexities and boil them down into simple, yet profound ideas (Adam Smith and the invisible hand, Darwin and evolution), leaders of (in) good-to-great companies develop a Hedgehog Concept that is simple but that reflects penetrating insight and deep understanding.”

BA Hedgehog What are you deeply passionate about: BA Education and Knowledge What you can be the best in the world at: Product Development (Macro Level) What drives your economic engine: Process Rigor An example of a BA Hedgehog, mostly mine as it applies to this Requirement Continuum Concept.

BA Hedgehog What are you deeply passionate about: BA Education and knowledge What you can be the best in the world at: Requirement Development (Micro Level) What drives your economic engine: Process Rigor

BA Hedgehog BA Education, Knowledge and execution Process Development, Rigor and execution Product Development, testing and implementation Good Process Good Product Repeatability Success BA Hedgehog

BA Hedgehog BA Education, Knowledge and execution Process Development, Rigor and execution Requirement Development, testing and implementation Good Process Good Product Repeatability Success BA Hedgehog

Transformations from good to great come about by a series of good decisions made consistently with a Hedgehog Concept, supremely well executed, accumulating one upon another, over a long period of time. The Requirement Continuum is a tool to be used to help execute supremely well.

Syllogism: To make good decisions, good (relevant) questions need to be asked. To determine what questions are relevant, the purpose of why a question needs to be asked is known. The reason a purpose exists, is because a business need has to be fulfilled. What is that business need?

Requirement Continuum An iterative requirement lifecycle Functional Decomposition Process Flow Feature Acceptance Criteria Acceptance Criteria User Story Acceptance Criteria User Story Acceptance Criteria Acceptance Criteria User Story Acceptance Criteria

Requirement Continuum An iterative requirement lifecycle Insert Solution Architect Insert System Analyst Insert Implementation Team Insert Waterfall jargon Functional Decomposition Feature User Story Acceptance Criteria Process Flow

Requirement Continuum An iterative requirement lifecycle Insert Solution Architect Insert System Analyst Insert Implementation Team Insert Waterfall jargon Functional Decomposition Feature User Story Acceptance Criteria Process Flow Will define the feature on the lowest level of the Functional Decomposition; business domain

Functional Decomposition Definition of the Requirement

Definition of a Requirement A requirement is technically defined as a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled. User stories are a form of requirements and contain the same core elements, just displayed in a different format.

Definition of a Requirement There are four categories of requirements:   Stakeholder Requirement Business Requirement Solution Requirement Transition Requirement

Definition of a Requirement Is there a fifth requirement?   “Technical Requirement”

Definition of a Requirement Stakeholder Requirement: A description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.

Definition of a Requirement Business Requirement: A representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.

Definition of a Requirement Solution Requirement: A capability or quality of a solution that meets the stakeholder requirements. Solution requirements can be divided into two sub-categories: functional requirements, and non-functional requirements or quality of service requirements.

Definition of a Requirement Solution Requirement: Is written for the Solution Provider, to give a sense of direction in all four dimensions of the solution: Functions, Data, Qualities, and Constraints.

Definition of a Requirement Functional Requirement: A capability that a solution must have in terms of the behavior and information the solution will manage.  

Definition of a Requirement   Non-Functional Requirement: A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.

Definition of a Requirement Transition Requirement: A requirement that describes the capabilities the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.

Definition of a Requirement Technical Requirement: A requirement that pertains to the technical aspects that your system must fulfill, such as performance-related issues, reliability issues, and availability issues. These types of requirements are often called quality of service (QoS) requirements, service-level requirements or non-functional requirements.

Definition of a Requirement Technical Requirement: Examples: The system shall be available 99.99% of the time for any 24-hour period. The home page shall be accessible by the consumer portal. The “check out” button shall be a radio button the consumer clicks online.

Requirement Statement Format Traditionally, a requirement has four constituent parts: Actor, is someone who is performing the action or is in need of something to be performed or delivered. Action, is the act of what the Actor needs; the verb to describe the performance of the Actor.

Requirement Statement Format Element, is the recipient of the Action being performed, or is influenced by that said Action. Condition, is something that may need to qualify the situation or statement. It may also be an explanation or a contextual addition of detail regarding the Element. The Condition of a Requirement does not always need to be included.

Requirement Statement Format Example: The Financial Specialist must provide payment data for the weekly report. Actor Action Element Condition

User Story Statement Format A user story has three main constituent parts that can easily be associated with the four main components of a classic requirement. The user story format:   As a(n)____________ I want to ___________ so I can _____________. IE. As a Developer, I want to write code so I can complete the project.

User Story Statement Conversion The Financial Specialist must provide payment data for the weekly report. Actor Action Element Condition As a Financial Specialist, I want to collect payment data so I can provide it for the weekly report.

Requirement Continuum An iterative requirement lifecycle Insert Solution Architect Insert System Analyst Insert Implementation Team Insert Waterfall jargon Functional Decomposition Feature User Story Acceptance Criteria Process Flow Functional Review or Exploratory Testing to find errors or impact issues

Requirement Continuum An iterative requirement lifecycle Insert Solution Architect Insert System Analyst Insert Implementation Team Insert Waterfall jargon Functional Decomposition Feature User Story Acceptance Criteria Process Flow Delivery Team Develops the process; QA validates (verify process) and tests. A lot of variation within companies, so the exact process may be different.

Requirement Continuum An iterative requirement lifecycle Insert Solution Architect Insert System Analyst Insert Implementation Team Insert Waterfall jargon Functional Decomposition Feature User Story Acceptance Criteria Process Flow Check and balance for structural design; traceability

Requirement Continuum An iterative requirement lifecycle Insert Solution Architect Insert System Analyst Insert Implementation Team Insert Waterfall jargon Functional Decomposition Feature User Story Acceptance Criteria Process Flow Check and balance for structural design; traceability Delivery Team Develops the process; QA validates (verify process) and tests. Will define the feature on the lowest level of the Functional Decomposition; business domain Functional Review or Exploratory Testing to find errors or impact issues

Requirement Continuum Key Points: The Requirement Continuum will present a Requirement Development Life Cycle that can be used in an Agile or Waterfall environment. Starting initially with a Functional Decomposition of the system (or capability) being analyzed or developed, taking the decomposition to the Feature level. These features will then be further developed by user stories that will provide acceptance criteria for the guardrails of what is considered complete and successful.

Requirement Continuum Key Points: QA will validate and test the process in a prototype environment, and when validated, the delivery team can develop. The development time frame represents the end of sprint. Each sprint is defined by the user stories developed. Now more features can be created, more user stories will define the features, and the cycle continues until the project is complete; Thus, a requirement continuum. Implementing this process will provide consistency every time a requirement set is needed to be created.

Business Analysis is not absolute Business Analysis is not absolute. There are no laws or legal precedence for what is considered proper business analysis. There is only a ‘suggested’ guideline; the BABOK. This is shaped and molded by the minds that contributed to its development. However, we can influence as well by creating a transcendent idea that frames a meaningful design, and establishes a compelling force in Business Analysis.

The End Questions? Or: Comments, Philosophical observations, Theoretical perspectives, Contentious objections, thought provoking contributions, or simply applauds of approval!