PowerPoint Presentation

Requirements EngineeringLecture 05National University FASTSeptember 19, 2015, 18:00 21:00Every Project has RequirementsFrederick Brooks eloquently stated the critical role of requirements to a software project in his classic 1987 essay, No Silver Bullet: Essence and Accidents of Software Engineering:The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.2Common Requirements RisksInsufficient User InvolvementCreeping User RequirementsAmbiguous RequirementsGold PlatingMinimal SpecificationOverlooked User ClassesInaccurate Planning33High Quality Requirements ProcessFewer requirements defectsReduced development reworkFewer unnecessary featuresLower enhancement costsFaster developmentFewer miscommunicationsReduced scope creepReduced project chaosMore accurate system-testing estimatesHigher customer and team member satisfaction44Characteristics of Excellent RequirementsRequirement Statement CharacteristicsCompleteCorrectFeasibleNecessaryPrioritizedUnambiguousVerifiable55Characteristics of Excellent RequirementsRequirements Specification CharacteristicsCompleteConsistentModifiableTraceable66Requirements RealitiesIf you dont get the requirements right, it doesnt matter how well you execute the rest of the projectRequirements development is a discovery and invention process, not just a collection processChange happensThe interests of all the project stakeholders intersect in the requirements processCustomer involvement is the most critical contributor to software quality77Requirements RealitiesThe customer is not always right, but the customer always has a pointThe first question an analyst should ask about a proposed new requirement is, Is this requirement in scope?Even the best requirements document cannot and should not replace human dialogueThe requirements might be vague, but the product will be specificYoure never going to have perfect requirements88