book

Mastering the Requirements Process, 4th Edition

by James Robertson, Suzanne Robertson, Adrian Reed

September 2024

Intermediate to advanced

656 pages

18h 44m

English

Addison-Wesley Professional

Read now

Unlock full access

Requirements Fundamental 1Requirements Fundamental 2Requirements Fundamental 3Requirements Fundamental 4Requirements Fundamental 5Requirements Fundamental 6Requirements Fundamental 7Requirements Fundamental 8Requirements Fundamental 9
A Requirements ProcessReview
The ProblemThe Real Business ProblemThe Goal StatementReviewResources
What Does Your Customer Value?Receiving ValueReviewResources
GoalsScopeA Presumed SolutionThe Context DiagramStakeholdersReviewResources
Customers and Their SegmentsPersonasPrioritizing the Customer SegmentsReviewResources
Understanding the WorkWhat Are Business Events?Why Business Events Are a Good IdeaFinding the Business EventsReady-made SolutionsReviewResources
Priority, Priority, PriorityEstimating EffortPrioritization FactorsApproval VotingBusiness Analysis PlanningReviewResources
The Likelihood of a Successful ProjectReady-made SolutionsDevelop the Business CaseTo Go or Not to GoAn Agile Approach to BlastoffReviewResources
Multiple CandidatesReviewResources
Types of PrototypesReviewResources
Prototyping with Ready-Made SolutionsChoosing Ready-Made SolutionsReviewResources
Creative TriggersLateral ThinkingRemoving ConstraintsCombinationReviewResources
ProbingExploringDouble-Loop LearningReviewResources
The Prototype as the SpecificationWhat to Do with the PrototypeEvolutionary and Sacrificial PrototypesReview
The ProblemAbstractionEssenceAsk Why—Again, and Again, and AgainReferred PainDisguised ProblemsReviewResources
Business EventsThe Business Use CaseTrawling the BUCsThe Desired Future BUCPrototyping and BUCsDescribing the BUCsReviewResources
How Now, Brown Cow?1How to Use the Brown Cow ModelReviewResources
BUC WorkshopsMechanics of a Successful WorkshopReviewResources
What Is a Scenario?The Essence of the BusinessAlternativesExceptionsMisuse Cases and Negative ScenariosReviewResources
The Business Event StoryReviewResources
NotationActivity DiagramsData Flow DiagramsBusiness Events and BUCsWhen to Use Process ModelsReviewResources
Data ModelsCRUD CheckReviewResources
ApprenticingInterviewingBusiness RulesRich PicturesCreativity WorkshopsDocument ArcheologyCustomer Experience AnalysisReviewResources
Uncovering the Functional RequirementsDeciding the Solution’s FunctionalityWriting the RequirementsThe Snow CardTechnological RequirementsLevel of GranularityConditional RequirementsAvoiding AmbiguityGrouping Requirements in Your SpecificationRequirements for Ready-Made ProductsReviewResources
PUCs and NFRsNon-functional Requirement TypesLook and Feel Requirements: Type 10Usability and Humanity Requirements: Type 11Performance Requirements: Type 12Operational and Environmental Requirements: Type 13Maintainability and Support Requirements: Type 14Security Requirements: Type 15Cultural Requirements: Type 16Compliance Requirements: Type 17Finding the Non-functional RequirementsDon’t Write a SolutionReviewResources
Why Does Fit Need a Criterion?The Rationale for the RationaleFinding Fit CriteriaScale of MeasurementFit Criteria for Non-functional RequirementsFit Criteria for StoriesFit Criteria for Functional RequirementsFit Criterion for Project PurposeFit Criteria for Solution ConstraintsReviewResources
Business Event StoriesProperties of Good StoriesINVESTNon-functional PropertiesReviewResources
Given/When/ThenReviewResources
Business OutcomesReviewResources
What Should You Automate?Iterative and Evolutionary DesignPrototypes Can HelpArchitectureReviewResources
User Experience = Information + FunctionalityReviewResources
The Request for ProposalSelecting the Best Ready-MadeReviewResources
Structure of the SpecificationResources
The Story MapGrowing the MapEnhancing the MapAdding Non-functional Requirements to the MapPrioritizing the MapUsing the Map IterativelyReviewResources
Within Scope?RelevancyCompleteness of a RequirementTesting the Fit CriteriaConsistent TerminologyViabilityRequirement or Solution?Value of the RequirementGold PlatingScope Creep and Your ProjectReviewResources
Have All Business Events Been Discovered?Define the Business DataCRUD CheckReviewResources
TraceabilityTracking Status of RequirementsChange ManagementReviewResources
Serial or Agile?A Common LanguageMaking It Your ProcessReviewResources
Why Do Things Go Wrong?Resources
Drivers of Human BehaviorReviewResources
Thinking About SystemsRipple EffectsExternal InfluencesThe Wider ViewUsing Data to Find Missing ConnectionsReviewResources
Using AI for Requirements DiscoveryAI in Business ProcessesReviewResources
Lessons LearnedReviewResources
The Value of Innovative RequirementsAn Innovation Process and RequirementsA Culture for InnovationThe Sanctity of the Incomplete IdeaInnovation and RequirementsResources
ContentsVolereRequirement TypesTesting RequirementsThe Snow Card1. The Purpose of the Project2. The Stakeholders3. Constraints4. Naming Conventions and Terminology5. Relevant Facts, Business Rules, and Assumptions6. The Scope of the Work7. Business Data Model and Data Dictionary8. The Scope of the Product9. Functional Requirements10. Look and Feel Requirements11. Usability and Humanity Requirements12. Performance Requirements13. Operational and Environmental Requirements14. Maintainability and Support Requirements15. Security Requirements16. Cultural Requirements17. Compliance Requirements18. Open Issues19. Ready-Made Solutions20. New Problems21. Tasks22. Migration to the New Product23. Risks24. Costs25. User Documentation and Training26. Waiting Room27. Ideas for Solutions
Stakeholder MapStakeholder Template
Using the ModelInterpreting the ModelExample Requirements Knowledge ModelDictionary for Requirements Knowledge ModelKnowledge Model Annotated with Template Section Numbers

Content preview from Mastering the Requirements Process, 4th Edition

21 Stories

Traditionally, stories are used by agile teams to specify a piece of functionality to be developed. While they are waiting to be developed, they are assembled into a backlog. These stories are known as “user stories.” However, as we are discovering requirements, it is premature to be thinking about users. The term “user” implies that you envisage someone sitting in front of a computer, which in turn implies that you have a solution in mind. As you are in the process of discovering the business problem, it is definitely unhelpful to be thinking about the solution.

In this chapter, we show you how to make use of stories in a different way. These are not “user stories,” but stories about requirements. This is a trawling technique, so ...