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

31 Determine the Extent of the Automation

Most of the time in this book we have been talking about requirements in a fairly abstract way. Now we need to think about how these abstract requirements might be brought into the physical world. We usually do this by automating them.

There is a caveat. When you decide on your automation, no matter how attractive the technology may be, you still have to satisfy the essence of the business problem. Designing business solutions is not about selecting the coolest technology and making beautiful products. It is about coming up with the most effective solution for implementing the essence. In this case, the objective is to determine an automated product that, apart from satisfying the requirements, is desirable ...