book

Software Requirements, 3rd Edition

by Karl Wiegers, Joy Beatty

August 2013

Intermediate to advanced

672 pages

25h 27m

English

Microsoft Press

Read now

Unlock full access

Benefits this book providesWho should read this bookLooking aheadCase studiesFrom principles to practiceErrata & book supportWe want to hear from youStay in touch
Software requirements definedSome interpretations of “requirement”The pure dictionary “requirement”Levels and types of requirementsWorking with the three levelsProduct vs. project requirementsRequirements development and managementRequirements developmentElicitationAnalysisSpecificationValidationRequirements managementEvery project has requirementsWhen bad requirements happen to good peopleInsufficient user involvementInaccurate planningCreeping user requirementsAmbiguous requirementsGold platingOverlooked stakeholdersBenefits from a high-quality requirements process
The expectation gapWho is the customer?The customer-development partnershipRequirements Bill of Rights for Software CustomersRight #1: To expect BAs to speak your languageRight #2: To expect BAs to learn about your business and your objectivesRight #3: To expect BAs to record requirements in an appropriate formRight #4: To receive explanations of requirements practices and deliverablesRight #5: To change your requirementsRight #6: To expect an environment of mutual respectRight #7: To hear ideas and alternatives for your requirements and for their solutionRight #8: To describe characteristics that will make the product easy to useRight #9: To hear about ways to adjust requirements to accelerate development through reuseRight #10: To receive a system that meets your functional needs and quality expectationsRequirements Bill of Responsibilities for Software CustomersResponsibility #1: To educate BAs and developers about your businessResponsibility #2: To dedicate the time that it takes to provide and clarify requirementsResponsibility #3: To be specific and precise when providing input about requirementsResponsibility #4: To make timely decisions about requirements when askedResponsibility #5: To respect a developer’s assessment of the cost and feasibility of requirementsResponsibility #6: To set realistic requirement priorities in collaboration with developersResponsibility #7: To review requirements and evaluate prototypesResponsibility #8: To establish acceptance criteriaResponsibility #9: To promptly communicate changes to the requirementsResponsibility #10: To respect the requirements development processCreating a culture that respects requirementsIdentifying decision makersReaching agreement on requirementsThe requirements baselineWhat if you don’t reach agreement?Agreeing on requirements on agile projects
A requirements development process frameworkGood practices: Requirements elicitationGood practices: Requirements analysisGood practices: Requirements specificationGood practices: Requirements validationGood practices: Requirements managementGood practices: KnowledgeGood practices: Project managementGetting started with new practices
The business analyst roleThe business analyst’s tasksEssential analyst skillsEssential analyst knowledgeThe making of a business analystThe former userThe former developer or testerThe former (or concurrent) project managerThe subject matter expertThe rookieThe analyst role on agile projectsCreating a collaborative team
Defining business requirementsIdentifying desired business benefitsProduct vision and project scopeConflicting business requirementsVision and scope document1. Business requirements1.1 Background1.2 Business opportunity1.3 Business objectives1.4 Success metrics1.5 Vision statement1.6 Business risks1.7 Business assumptions and dependencies2. Scope and limitations2.1 Major features2.2 Scope of initial release2.3 Scope of subsequent releases2.4 Limitations and exclusions3. Business context3.1 Stakeholder profiles3.2 Project priorities3.3 Deployment considerationsScope representation techniquesContext diagramEcosystem mapFeature treeEvent listKeeping the scope in focusUsing business objectives to make scoping decisionsAssessing the impact of scope changesVision and scope on agile projectsUsing business objectives to determine completion

User classesClassifying usersIdentifying your user classesUser personasConnecting with user representativesThe product championExternal product championsProduct champion expectationsMultiple product championsSelling the product champion ideaProduct champion traps to avoidUser representation on agile projectsResolving conflicting requirements
Requirements elicitation techniquesInterviewsWorkshopsFocus groupsObservationsQuestionnairesSystem interface analysisUser interface analysisDocument analysisPlanning elicitation on your projectPreparing for elicitationPerforming elicitation activitiesFollowing up after elicitationOrganizing and sharing the notesDocumenting open issuesClassifying customer inputHow do you know when you’re done?Some cautions about elicitationAssumed and implied requirementsFinding missing requirements
Use cases and user storiesThe use case approachUse cases and usage scenariosPreconditions and postconditionsNormal flows, alternative flows, and exceptionsExtend and includeAligning preconditions and postconditionsUse cases and business rulesIdentifying use casesExploring use casesValidating use casesUse cases and functional requirementsUse cases onlyUse cases and functional requirementsFunctional requirements onlyUse cases and testsUse case traps to avoidBenefits of usage-centric requirements
A business rules taxonomyFactsConstraintsAction enablersInferencesComputationsAtomic business rulesDocumenting business rulesDiscovering business rulesBusiness rules and requirementsTying everything together
The software requirements specificationLabeling requirementsSequence numberHierarchical numberingHierarchical textual tagsDealing with incompletenessUser interfaces and the SRSA software requirements specification template1. Introduction1.1 Purpose1.2 Document conventions1.3 Project scope1.4 References2. Overall description2.1 Product perspective2.2 User classes and characteristics2.3 Operating environment2.4 Design and implementation constraints2.5 Assumptions and dependencies3. System features3.x System feature X3.x.1 Description3.x.2 Functional requirements4. Data requirements4.1 Logical data model4.2 Data dictionary4.3 Reports4.4 Data acquisition, integrity, retention, and disposal5. External interface requirements5.1 User interfaces5.2 Software interfaces5.3 Hardware interfaces5.4 Communications interfaces6. Quality attributes6.1 Usability6.2 Performance6.3 Security6.4 Safety6.x [Others]7. Internationalization and localization requirements8. [Other requirements]Appendix A: GlossaryAppendix B: Analysis modelsRequirements specification on agile projects
Characteristics of excellent requirementsCharacteristics of requirement statementsCompleteCorrectFeasibleNecessaryPrioritizedUnambiguousVerifiableCharacteristics of requirements collectionsCompleteConsistentModifiableTraceableGuidelines for writing requirementsSystem or user perspectiveWriting styleLevel of detailRepresentation techniquesAvoiding ambiguityAvoiding incompletenessSample requirements, before and after
Modeling the requirementsFrom voice of the customer to analysis modelsSelecting the right representationsData flow diagramSwimlane diagramState-transition diagram and state tableDialog mapDecision tables and decision treesEvent-response tablesA few words about UML diagramsModeling on agile projectsA final reminder
Modeling data relationshipsThe data dictionaryData analysisSpecifying reportsEliciting reporting requirementsReport specification considerationsA report specification templateDashboard reporting
Software quality attributesExploring quality attributesDefining quality requirementsExternal quality attributesAvailabilityInstallabilityIntegrityInteroperabilityPerformanceReliabilityRobustnessSafetySecurityUsabilityInternal quality attributesEfficiencyModifiabilityPortabilityReusabilityScalabilityVerifiabilitySpecifying quality requirements with PlanguageQuality attribute trade-offsImplementing quality attribute requirementsConstraintsHandling quality attributes on agile projects
Prototyping: What and whyMock-ups and proofs of conceptThrowaway and evolutionary prototypesPaper and electronic prototypesWorking with prototypesPrototype evaluationRisks of prototypingPressure to release the prototypeDistraction by detailsUnrealistic performance expectationsInvesting excessive effort in prototypesPrototyping success factors
Why prioritize requirements?Some prioritization pragmaticsGames people play with prioritiesSome prioritization techniquesIn or outPairwise comparison and rank orderingThree-level scaleMoSCoW$100Prioritization based on value, cost, and risk
Validation and verificationReviewing requirementsThe inspection processParticipantsInspection rolesEntry criteriaInspection stagesExit criteriaDefect checklistRequirements review tipsRequirements review challengesPrototyping requirementsTesting the requirementsValidating requirements with acceptance criteriaAcceptance criteriaAcceptance tests
Why reuse requirements?Dimensions of requirements reuseExtent of reuseExtent of modificationReuse mechanismTypes of requirements information to reuseCommon reuse scenariosSoftware product linesReengineered and replacement systemsOther likely reuse opportunitiesRequirement patternsTools to facilitate reuseMaking requirements reusableRequirements reuse barriers and success factorsReuse barriersReuse success factors
Estimating requirements effortFrom requirements to project plansEstimating project size and effort from requirementsRequirements and schedulingFrom requirements to designs and codeArchitecture and allocationSoftware designUser interface designFrom requirements to testsFrom requirements to success
Limitations of the waterfallThe agile development approachEssential aspects of an agile approach to requirementsCustomer involvementDocumentation detailThe backlog and prioritizationTimingEpics, user stories, and features, oh my!Expect changeAdapting requirements practices to agile projectsTransitioning to agile: Now what?
Expected challengesRequirements techniques when there is an existing systemPrioritizing by using business objectivesMind the gapMaintaining performance levelsWhen old requirements don’t existWhich requirements should you specify?Level of detailTrace DataHow to discover the requirements of an existing systemEncouraging new system adoptionCan we iterate?
Requirements for selecting packaged solutionsDeveloping user requirementsConsidering business rulesIdentifying data needsDefining quality requirementsEvaluating solutionsRequirements for implementing packaged solutionsConfiguration requirementsIntegration requirementsExtension requirementsData requirementsBusiness process changesCommon challenges with packaged solutions
Appropriate levels of requirements detailAcquirer-supplier interactionsChange managementAcceptance criteria
Modeling business processesUsing current processes to derive requirementsDesigning future processes firstModeling business performance metricsGood practices for business process automation projects
Overview of business analytics projectsRequirements development for business analytics projectsPrioritizing work by using decisionsDefining how information will be usedInformation usage by peopleInformation usage in systemsSpecifying data needsBig dataData-based (not “database”) requirementsDefining analyses that transform the dataThe evolutionary nature of analytics
System requirements, architecture, and allocationModeling real-time systemsContext diagramState-transition diagramEvent-response tableArchitecture diagramPrototypingInterfacesTiming requirementsQuality attributes for embedded systemsThe challenges of embedded systems
Requirements management processThe requirements baselineRequirements version controlRequirement attributesTracking requirements statusResolving requirements issuesMeasuring requirements effortManaging requirements on agile projectsWhy manage requirements?
Why manage changes?Managing scope creepChange control policyBasic concepts of the change control processA change control process description1. Purpose and scope2. Roles and responsibilities3. Change request status4. Entry criteria5. Tasks5.1 Evaluate change request5.2 Make change decision5.3 Implement the change5.4 Verify the change6. Exit criteria7. Change control status reportingAppendix: Attributes stored for each requestThe change control boardCCB compositionCCB charterMaking decisionsCommunicating statusRenegotiating commitmentsChange control toolsMeasuring change activityChange impact analysisImpact analysis procedureImpact analysis templateChange management on agile projects
Tracing requirementsMotivations for tracing requirementsThe requirements traceability matrixTools for requirements tracingA requirements tracing procedureIs requirements tracing feasible? Is it necessary?
Requirements development toolsElicitation toolsPrototyping toolsModeling toolsRequirements management toolsBenefits of using an RM toolRM tool capabilitiesSelecting and implementing a requirements toolSelecting a toolSetting up the tool and processesFacilitating user adoption
How requirements relate to other project processesRequirements and various stakeholder groupsGaining commitment to changeFundamentals of software process improvementRoot cause analysisThe process improvement cycleAssess current practicesPlan improvement actionsCreate, pilot, and roll out processesEvaluate resultsRequirements engineering process assetsRequirements development process assetsRequirements management process assetsAre we there yet?Creating a requirements process improvement road map
Fundamentals of software risk managementElements of risk managementDocumenting project risksPlanning for risk managementRequirements-related risksRequirements elicitationRequirements analysisRequirements specificationRequirements validationRequirements managementRisk management is your friend
Common signs of requirements problemsCommon barriers to implementing solutionsRequirements troubleshooting guideProcess issuesProduct issuesPlanning issuesCommunication issuesElicitation issuesAnalysis issuesSpecification issuesValidation issuesRequirements management issuesChange management issues
Vision and Scope Document1. Business Requirements1.1 Background1.2 Business Opportunity1.3 Business Objectives1.4 Success Metrics1.5 Vision Statement1.6 Business Risks1.7 Business Assumptions and Dependencies2. Scope and Limitations2.1 Major Features2.2 Scope of Initial and Subsequent Releases2.3 Limitations and Exclusions3. Business Context3.1 Stakeholder Profiles3.2 Project Priorities3.3 Deployment ConsiderationsUse CasesSoftware Requirements Specification1. Introduction1.1 Purpose1.2 Document Conventions1.3 Project Scope1.4 References2. Overall Description2.1 Product Perspective2.2 User Classes and Characteristics2.3 Operating Environment2.4 Design and Implementation Constraints2.5 Assumptions and Dependencies3. System Features3.1 Order Meals from Cafeteria3.1.1 Description3.1.2 Functional Requirements3.2 Order Meals from Restaurants3.3 Create, View, Modify, and Delete Meal Subscriptions3.4 Create, View, Modify, and Delete Cafeteria Menus4. Data Requirements4.1 Logical Data Model4.2 Data Dictionary4.3 Reports4.3.1 Ordered Meal History Report4.4 Data Integrity, Retention, and Disposal5. External Interface Requirements5.1 User Interfaces5.2 Software Interfaces5.3 Hardware Interfaces5.4 Communications Interfaces6. Quality Attributes6.1 Usability Requirements6.2 Performance Requirements6.3 Security Requirements6.4 Safety Requirements6.5 Availability Requirements6.6 Robustness RequirementsAppendix A: Analysis ModelsBusiness Rules
References

Content preview from Software Requirements, 3rd Edition

Chapter 3. Good practices for requirements engineering

“Welcome to the group, Sarah,” said the project manager, Kristin. “We’re looking forward to having you help us with the requirements for this project. I understand that you were a business analyst in your previous job. Do you have some idea of how we should get started here?”

“Well,” Sarah replied, “I was thinking I should just interview some users and see what they want. Then I’ll write up what they tell me. That should give the developers a good place to start. That’s mostly what we did before. Do you know some users I could talk to?”

“Hmmm. Do you think that will be good enough for this type of project?” Kristin asked. “We tried that approach before, but it didn’t work out very well. I was ...