An Example - RequirementsDevelopment5.3.2.1 The specific intended use of the system to be developedshall be analyzed to specify system requirements. The systemrequirements specification shall describe: functions andcapabilities of the system; business, organizational and userrequirements; safety, security, human-factors engin<strong>ee</strong>ring(ergonomics), interface, operations, and maintenancerequirements; design constraints and qualification requirements.The system requirements specification shall be documented.5.3.4.1 The developer shall establish and document softwarerequirements, including the quality characteristics specifications, SP 2.1-1 Establish Productand Product Componentdescribed below. . . .Requirementsa) Functional and capability specifications, including performance,physical characteristics, and environmental conditions underwhich the software item is to perform;b) Interfaces external to the software item;c) Qualification requirements;d) Safety specifications, including those related to methods ofoperation and maintenance, environmental influences, andpersonnel injury;e) Security specifications, including those related to compromiseof sensitive information . . .– Establish and maintain, fromthe customer requirements,product and productcomponent requirementsessential to product andproduct componenteffectiveness and affordability• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 1220<strong>7.</strong>0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications119An Example - RequirementsDevelopment<strong>7.</strong>2 Build a well-formed requirementThe analysts carry out this subphase by doing the following:a) Ensuring that each requirement is a necessary, short, definitivestatement of n<strong>ee</strong>d (capability, constraints);b) Defining the appropriate conditions (quantitative or qualitativemeasures) for each requirement and avoiding adjectives such as SP 2.1-1 Establish Product“resistant” or “industry wide;”c) Avoiding and requirements Product pitfalls Component(s<strong>ee</strong> 6.4);Requirementsd) Ensuring the readability of requirements, which entails the following:1) Simple words/phrases/concepts;2) Uniform arrangement and relationship;– Establish maintain, from3) Definition of unique words, symbols, and notations;4) The use the of grammatically customer correct requirements,language and symbology.e) Ensuring testability.product and productExample:<strong>Capability</strong>: component Move people betw<strong>ee</strong>n requirementsLos Angeles and New YorkCondition: Cruising sp<strong>ee</strong>d of 200 km/hressential to product andConstraint: Maximum sp<strong>ee</strong>d of 300 km/hrWell-formed product requirement: componentThis system should move people betw<strong>ee</strong>nLos Angeles and New York at an optimal cruising sp<strong>ee</strong>d of 200 km/hreffectiveness and affordabilitywith a maximum sp<strong>ee</strong>d of 300 km/hr.• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 1220<strong>7.</strong>0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications12060
An Example - RequirementsDevelopment SP 2.1-1 Establish Productand Product ComponentRequirements– Establish and maintain, fromthe customer requirements,product and productcomponent requirementsessential to product andproduct componenteffectiveness and affordability• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 1220<strong>7.</strong>0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications121An Example - RequirementsDevelopment5.3.2 FunctionsFunctional requirements should define the fundamental actions thatmust take place in the software in accepting and processing the inputsand in processing and generating the outputs. These are generallylisted as “shall” statements starting with “The system shall”These include:a) Validity checks on the inputsb) Exact SP sequence 2.1-1 of Establish operations Productc) Responses to abnormal situations, including:1) Overflow and Product Component2) Communication facilitiesRequirements3) Error handling and recoveryd) Effect–ofEstablishparametersand maintain, frome) Relationship of outputs to inputs . . .1) It may the be appropriate customer partition requirements,the functional requirements intosubfunctionsproductor subprocesses.and productThis doesnot imply that the software design will also be partitioned that way.5.3.3 Performance component requirements requirementsThis subsection should specify both the static and the dynamicessential to product andnumerical requirements placed on the softwareor on product human interaction component with the software as a whole. Staticnumerical requirements may include th<strong>ee</strong>ffectiveness and affordabilityfollowing:a) The number of terminals to be supported;b) The number of simultaneous users to be supported;c) Amount and type of information to be handled.• ISO/IEC 15288, System Life CycleProcesses– Clause 5.5.3 - Requirements AnalysisProcess• IEEE/EIA 1220<strong>7.</strong>0, Software LifeCycle Processes– Clause 5.3.2 - System RequirementsAnalysis– Clause 5.3.4 - Software requirementsanalysis• IEEE 1233, Guide for DevelopingSystem Requirements Specifications• IEEE 830, Software RequirementsSpecifications12261