WIXLIB

Requirements ManagementJohn HrastarNASA Project Management ConferenceMarch 30-31, 2004University of Maryland Conference Center

IntroductionThree aspects of requirements management Requirements in the beginning Requirements in the middle What are they?How are they derived?How are they maintainedCan they be changed? Requirements in the end VerificationValidation Requirements Management 3-30-31, 20042

Introduction Dictionary definitions “ a thing demanded or obligatory ” “ a need or necessity” “ some quality or performance demanded”Strong wordsRequirements Management 3-30-31, 20043

Introduction Requirements are the single thread that goes through a projectfrom conception through build, test and flight Whole project is constructed so you can meet the requirementsBased on the need to measure a physical phenomena high levelrequirements are envisioned for a system to meet the need. Same quality or performance is demanded to be able to make thenecessary measurements Requirements are then refined, expanded, and flowed down tolower levels through an iterative process They are decomposed to the lowest levels where one person isresponsible for that system of interest.Requirements Management 3-30-31, 20044

IntroductionRequirements run through the entire Project cycle.Requirements Management 3-30-31, 20045

Introduction“Project requirements start with what the user reallyneeds ( not what the provider perceives that the userneeds) and end when those needs are satisfied”“Visualizing Project Management”Forsberg, Moog, CottermanRequirements Management 3-30-31, 20046

Customers, Users, Stakeholders, Developers User: Anyone who will work with the system. Usuallythe scientists (PI’s) looking for the measurements. Customer: Person or entity you are responding to.This includes the users, Program Office, EnterpriseStakeholder: Anyone affected by the systemincluding users, customers, developers Developers: Team that develops the system for theusersItIt isis criticalcritical thatthat allall toptop levellevel requirementsrequirements areare wellwell iteratediteratedbetweenbetween users,users, customers,customers, stakeholders,stakeholders, developersdevelopersRequirements Management 3-30-31, 20047

Failure to Satisfy CustomersNeedsRequirements Management 3-30-31, 20048

Requirements Process Iterative process between stakeholders, users, customers, anddevelopers at the beginning What needs to be done? What can be done? User must understand what can be developedWhat new technologies are required to achieve feasibility?Maintain the interaction among these groups throughout development Developers must understand user needsRe-evaluate needsClarify needsChange requirements if necessaryMust separate ‘needs” and “wants” during concept selection Requirements are agreed “needs” of the user with what can be doneAdditional “wants” (like to have) are over-specification which should bedeletedChallenging project might require technology development to high TRLsbefore “buildable” requirements can be metRequirements Management 3-30-31, 20049

Requirements ProcessRequirements Management 3-30-31, 200410

Requirements Development What are the top level requirements? What must the system do? Functional requirementsHow well must it perform? Concept of operations document to set contextPerformance requirementsHow do we record requirements? Organized into a hierarchy that flows through to lower systems of interestRequirements flow follows the Project Product Breakdown StructureLevels of requirements are shown in a document treeLevel I requirements defined in the Project Plan, also include the MissionSuccess CriteriaOrganize requirements into functional and performance Functional – what it must doPerformance – how well it must do itPerformance Requirements must be validated and verifiableRequirements Management 3-30-31, 200411

Operations Concept Development Puts the requirements in contextDescribes how the design can accomplish the missiondescribed by the objectivesDone early in the mission feasibility studiesTrade studies to developDescribes system characteristics and performance from anoperations perspectiveHelps better understand the capability and performance of thesystem within the proposed mission, use, and functionHelps scope mission development costs, schedule, constraintsProvides information on:What WhoWhyWhereWhenHowServes as a validation reference for design throughout the lifecycleRequirements Management 3-30-31, 200412

Concept and Architecture Solution SpaceLessons LearnedtenmonirnvEtnemonrivEnStandards and Best PracticesBusiness Case & User CONOPSLegaStakeholder ConstraintStakeholder ConstraintEliminated LowValue FeaturescySysSystemyLegacTechnoConcept Trade SpaceStakeholder ConstraintteUser #3mNeeds,Expectations,andUser #2 Needs, Expectations, andSolutionsSystem Requirements SolutionsValueDrivenConceptSolutionConceptandnslo #1UsergytioUser #4aitLiNeeds, Expectations,mNeeds,Expectations,miLEliminated Lowit aand Solutionsand SolutionsValue FeaturestigyBusiness Case & User CONOPSStandards and Best straintsnchTeLessons LearnedRequirements Management 3-30-31, 200413

Mission Success CriteriaFull Mission Success Criteria: Requirements that must bemet for full mission success(Cost, Schedule, Technical)Some options availableincluding descope, whichcan be exercised toimplement a successfulscience mission but onethat is less than the fullmissionMinimum Mission Success Criteria: Requirements that mustbe met for minimum missionsuccess (Cost, Schedule,Technical)Below this level, the mission is not worth continuingRequirements Management 3-30-31, 200414

Requirements Flow: Decomposition and Integration Decomposition Fabrication and assembly of the system of interestIntegration Successive combining and testing of hardware and software toprogressively demonstrate performance and compatibility ofvarious systems of interestVerification Hierarchical, functional, and physical partitioning of a system ofinterest into lower levels of systems of interest that can be assignedto a responsible managerDetermination that the system meets all specified requirementsValidation Determination that the system satisfies what the customer (user)needsRequirements Management 3-30-31, 200415

Hierarchical Relationships for Systems of InterestProjectSystem of InterestSpacecraftSpacecraftGroundGround systemsystemSystem of InterestSubsystemSubsystemSubsystemSubsystemSystem of InterestComponentComponentRequirements Management 3-30-31, 2004ComponentComponent16

Hierarchical Relationships for Systems of InterestAntennaAntenna ersFiltersRFRF SwitchSwitchDiplexersDiplexersTransponderSystem of InterestRequirements Management 3-30-31, 2004CommunicationsSystem of InterestSatelliteSystem of Interest17

Decomposition and Integration CycleIntegrateIntegrateSystemSystem ofof InterestInterestVerifyVerify && tsationIntegrateIntegrate LowerLower LevelLevelSystemSystem ofof InterestInterestIntenitioefinLowerLower LevelLevel ofof SystemSystemofof InterestInterest poscomDeIntegrateIntegrate NextNextHigherHigher LevelLevelSystemSystem ofof InterestInterestNextNext LevelLevel ofof SystemSystemofof InterestInterest RequirementsRequirementsFabricationFabrication ofofSystemSystem ofof InterestInterestRequirements Management 3-30-31, 2004Adapted from SP 610518

System Specification Allocation to Lower LeveRequirements Management 3-30-31, 200419

Managing Requirements During Development Requirements are not always static during development Legitimate new requirements might be added System design must be reviewed to assess the impactNew resources must be added; e.g., budget, weight, schedule, etc.Requirements can “creep” if one is not vigilant They can change for many different reasonsAddition of a capability that is highly desirable and seems to be“free”It is not freeContingency funds are necessary to correct problems in thedevelopment process to satisfy needed requirements They are not to be used to accommodate requirements creepThis is the only discretionary money a Project Manager hasRequirements Management 3-30-31, 200420

Managing Requirements During Development Examples STEREO – KSC clean room requirements GRO – Level I requirement on fuel load TDRSS – Major changes on a fixed-price contract EOSDIS – Missed recognition of technology changes thatcould have caused requirements changes TIMED – Missed recognition of changing environment thateventually led to requirements changesRequirements Management 3-30-31, 200421

Validation and Verification “The purpose of verification is to ensure that thesubsystems conform to what was designed andinterface with each other as expected in allrespects ” “Validation consists of ensuring that the interfacedsubsystems achieve their intended results.”“While validation is even more important thanverification, it is usually much more difficult toaccomplish” (Very clear example later.) Verification: “Is the system built right?”Validation: “Has the right system been built?”NASA Systems Engineering HandbookRequirements Management 3-30-31, 200422

Validation Validation assures the design will meet mission objectives Validation begins at the start of the project cycle Validation plan set when the user requirements baseline is setConfirmation at the control gatesValidation is a formal continuous confirmation that the productwill meet the users needs. “Will the customer smile?”Is the right system being built?Requirements vs. needsSpecification vs. needsDesign vs. needsProduct vs. needsValidation methods Focus on operational scenarios and how they are supported, I.e.the operations conceptValidate against architecture and designRequirements Management 3-30-31, 200423

Validation Stakeholders interaction is critical Keep going back to stakeholders to validate what you aredeveloping is what he/she wantsVerification program is validated to requirements Assure all requirements are verified Assure the traceability of the parent and child requirementsEnd-to-end testing is the ultimate test for bothverification and validationRequirements Management 3-30-31, 200424

Failure to ValidateRequirements Management 3-30-31, 200425

Mission Validation ptConceptMission Validation BasisValidatethese tothe e& DesignRequirementsValidate to Assure Mutual ConsistencyRequirements Management 3-30-31, 200426

Verification Make sure the team builds the system right Verify design and implementation against the requirements Proof of compliance with the specification Verification process identifies the verification item, the method(analysis, inspection, test) and review of the verification results “Test as you fly and fly as you test Need to identify anything not tested in flight configuration andascertain and mitigate risk Test planning should include environment exposure as well asrequirements for comprehensive, functional, aliveness tests, etc. End-to-end testing from the science input through the sciencedata output is the best verification and validation testRequirements Management 3-30-31, 200427

Verification Object: Ensure all functional, performance and designrequirements (from Level I through Level n) have been met Begins in Phase A, increases in Phase B with the refinement ofrequirements, cost, schedule. More detailed plans in Phase C(design). Phase D (development) includes the qualification andacceptance verification Verification methods and techniques: Test – Measured compliance with metrics Analysis – Predicted compliance with history Demonstration – Observed compliance without metrics Inspection – Compliance with drawings, documentationNASA Systems Engineering HandbookRequirements Management 3-30-31, 200428

Requirements Verification MatrixRequirements Management 3-30-31, 200429