Tutorial: Requirements Specification Elaboration

1. Tutorial:Requirements Specification Elaboration Bruno Soares Gonçalves

2. Technical requirements specification purpose and description The technical requirements specification is a document through which a customer expresses his needs (or those that he is responsible for expressing) and the related environment and constraints in terms of technical requirements allowing for potential suppliers to propose the best technical and programmatic solutions. The requirements documents organize and communicate requirements to the customer and other stakeholders and the technical community. The intention of the technical requirements specification is not to assume or refer to specific solutions

3. Why focus on requirements? The hardest single part of building a system is deciding what to build... No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Adapted from Brooks, Fredrick P., Jar. “No Silver Bullet: Essence and Accidents of Software Engineering”. IEEE Computer, 10-19, April 1987

4. Technical Requirements Definition Process Technical Requirements Definition Process transforms the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements expressed as “shall” statements that can be used for defining a design solution for the Product Breakdown Structure (PBS) model and related enabling products. The TS is the technical reference for the qualification of the design and for the acceptance of the end product.

5. Technical Requirements Definition Process • The process is recursive and iterative and develops the stakeholders’ requirements, product requirements, and lower level product/component requirements • e.g., PBS model products such as systems or subsystems and related enabling products such as external systems that provide or consume data. • Requirements should enable description of all • Inputs, • Outputs • Required relationships betweeninputs and outputs. • Technical requirements definition activities apply to the definition of all technical requirements from the project, and system levels down to the lowest level product/component requirements document.

6. Technical Requirements definition process

7. Requirements Process

8. Requirements Analysis Should result in a clear understanding of: • Functions: What the system has to do, • Performance: How well the functions have to be performed, • Interfaces: Environment in which the system will perform, and • Other requirements and constraints.

9. Structure Requirements should be communicated in a structured manner to ensure that the customer and technical community are able to: Identifyrequirements that are derived from other requirements; Organize requirements of different levels of detail into their appropriate levels; Verify the completeness of the set of requirements; Identify inconsistencies among requirements; Clearly identify the capabilities, conditions, and constraints for each requirement; Develop a common understanding with the customer of the purpose and objectives of the set of requirements; Identify requirements that will complete the SyRS.

10. Properties of a requirement Each requirement should possess the following properties: • Abstract: Each requirement should be implementation independent. • Unambiguous: Each requirement should be stated in such a way so that it can be interpreted in only one way. • Traceable: For each requirement it should be feasible to determine a relationship between specific documented customer statement(s) of need and the specific statements in the definition of the system given in the SyRS as evidence of the source of a requirement. • Validatable: Each requirement should have the means to prove that the system satisÞes the requirements.

11. Properties of the collection The collection of requirements should have the following properties: Unique set: Each requirement should be stated only once. Normalized: Requirements should not overlap (i.e, they shall not refer to other requirements or the capabilities of other requirements). Linked set: Explicit relationships should be defined among individual requirements to show how the requirements are related to form a complete system. Complete: An SyRS should include all the requirements identified by the customer, as well as those needed for the definition of the system. Consistent: SyRS content should be consistent and non-contradictory in the level of detail, style of requirement statements, and in the presentation of material. Bounded: The boundaries, scope, and context for the set of requirements should be identified. Modifiable: The SyRS should be modifiable. Clarity and non-overlapping requirements contribute to this. Configurable: Versions should be maintained across time and across instances of the SyRS. Granular: This should be the level of abstraction for the system being defined.

12. System Requirements Specification outline

13. Technical requirements specification:Content A technical requirements specification is typically composed of three major sets of information: • General information related to the context of the document (e.g. administrative information, normative documents and informative documents); • General information related to the context of the project, the product or system; • Technical requirements

14. Technical requirements specification: General information The specification provides general information related to its context: • Administrative information: to provide all the information regarding, for example, the owner, status, identification, distribution list, and management rule; • Scope: to define without ambiguity the subject of the TS and aspects covered, thereby indicating limits of applicability; • References: to list all the normative (applicable) documents and standards, with titles, issue revision, and dates that are referred to in the TS; • Terms, definitions and abbreviated terms: to list the specific terms and abbreviated terms used in the TS.

15. Technical requirements specification:Context Also provides general information related to the context of the project, product or system: • to provide a clear and rapid understanding of the project and the main needs or mission statements; • to give indications of the market as additional information, as well as information about the context of the project and the objectives (situation of the project in a larger programme, further developments); • to provide information on the environment and its constraints; • to detail the different situations of the product or system life cycle.

16. Type of requirements • Customer Requirements: Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability • Functional Requirements: The necessary task, action or activity that must be accomplished. Functional (what has to be done) requirements identified in requirements analysis will be used as the toplevel functions for functional analysis. • e.g., “The product shall analyse the surface of Mars and transmit the data so that it is at the disposal of the scientific community”. • Performance Requirements: The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements. • Design Requirements: The “build to,”“code to,”and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. • Derived Requirements: Requirements that are implied or transformed from higher-level requirement. • E.g., a requirement for long range or high speed may result in a design requirement for low weight. • Allocated Requirements: A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. • E.g., a 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

17. Types of requirements • • Mission requirements, related to a task, a function, a constraint, or an action induced by the mission scenario. • e.g., “The product shall be designed to be put in its final position after a transfer duration shorter than 90 days”. • • Interface requirements, related to the interconnection or relationship characteristics between the product and other items. • e.g., “The product shall dialogue with the ground segment using telemetry”. • • Environmental requirements, related to a product or the system environment during its life cycle; this includes the natural environments (e.g. planet interactions, free space and dust) and induced environments (e.g. radiation, electromagnetic, heat, vibration and contamination). • e.g., “The product shall operate within the temperature range from 30 ºC to 50 ºC”. • • Operational requirements, related to the system operability. This includes operational profiles and the utilization environment and events to which the product shall respond (e.g. autonomy, control and contingency) for each operational profile. • e.g., “The product shall be designed to accept control of the viewing function from the ground segment”

18. Types of requirements • • Human factor requirements, related to a product or a process adapted to human capabilities considering basic human characteristics. • e.g., “The product shall display the information with no more than two windows on the screen at the same time”. • • (Integrated) logistics support requirements, related to the (integrated) logistics support considerations to ensure the effective and economical support of a system for its life cycle. • • Physical requirements, that establish the boundary conditions to ensure physical compatibility and that are not defined by the interface requirements, design and construction requirements, or referenced drawings. This includes requirements related to mechanical characteristics, electrical isolation and chemical composition (e.g. weight and dimensional limits). • e.g., For example: “The product shall have a mass of (30 ± 0,1) kg”. • • Product assurance (PA) induced requirements, Requirements related to the relevant activities covered by the product assurance. This can include the following subjects: Reliability, availability, maintainability, Safety, and Quality assurance.

19. Types of technical requirements • • Configuration requirements, related to the composition of the product or its organization. • e.g., “The product shall have 7 power modules with 2 power outlets per engine”. • • Design requirements, related to the imposed design and construction standards such as design standards, selection list of components or materials, interchangeability, safety or margins. • e.g., “The receiver shall use a phase-lock loop (PLL)”. • • Verification requirements. related to the imposed verification methods, such as compliance o verification standards, usage of test methods or facilities. • e.g., “The thermal balance test shall be performed using solar illumination”.

20. Functional Requirements • The functional requirements need to be specified for all intended uses of the product over its entire lifetime. • Functional analysis is used to draw out both functional and performance requirements. • Requirements are partitioned into groups, based on established criteria (e.g., similar functionality, performance, or coupling, etc.), to facilitate and focus the requirements analysis. • Functional and performance requirements are allocated to functional partitions and subfunctions, objects, people, or processes. • Sequencing of time-critical functions is considered. • Each function is identified and described in terms of inputs, outputs, and interface requirements from the top down so that the decomposed functions are recognized as part of larger functional groupings. • Functions are arranged in a logical sequence so that any specified operational usage of the system can be traced in an end-to-end path to indicate the sequential relationship of all functions that must be accomplished by the system.

21. Performance Requirements • Performance requirements quantitatively define how well the system needs to perform the functions. • Performance requirements draws out by asking the following types of questions: • How often and how well, • To what accuracy (e.g., how good does the measurement need to be), • What is the quality and quantity of the output, under what stress (maximum simultaneous data requests) or environmental conditions, for what duration, • At what range of values, • At what tolerance, • At what maximum throughput or bandwidth capacity. • Wherever possible, define the performance requirements in terms of • 1) Threshold value (the minimum acceptable value needed for the system to carry out its mission) • 2) Baseline level of performance desired. • Specifying performance in terms of thresholds and baseline requirements provides the system designers with trade space in which to investigate alternative designs.

22. Interface Requirements • It is important to defineall interface requirements for the system, including those to enabling systems, and the external interfaces from the boundaries between the product and the rest of the world. • Types of interfaces include: • Operational command and control, • Computer to computer, • Mechanical, • Electrical, • Thermal, • Data

23. Interface Requirements One useful tool in defining interfaces is the context diagram, which depicts the product and all of its external interfaces. Once the product components are defined, a block diagram showing the major components, interconnections, and external interfaces of the system should be developed to define both the components and their interactions.

24. Reliability Requirements • Ensure that the system (and subsystems, e.g., software and hardware) • can perform in the predicted environments and conditions as expected throughout the mission • has the ability to withstand certain numbers and types of faults, errors, or failures • e.g., withstand vibration, predicted data rates, command and/or data errors, single-event

25. Problems with Requirements Problems of requirements elicitation can be grouped into 3 categories: Problems of Scope: the requirements may address too little or too much information. Problems of Understanding: problems within groups as well as between groups such as users and developers. Problems of Volatility: the changing nature of requirements.

26. Usual causes of Problems with Requirements Problems of Scope • The boundary of the system is ill-defined • Unnecessary design information may be given Problems of Volatility • Requirements evolve over time Problems of Understanding • Users have incomplete understanding of their needs • Users have poor understanding of computer capabilities and limitations • Analysts have poor knowledge of problem domain • User and analyst speak different languages • Ease of omitting “obvious”information • Conflicting views of different users • Requirements are often vague and untestable, e.g., “user friendly” and “robust”

27. Benefits of Well-Written Requirements

28. How to Write a Good Requirements • Use of Correct Terms • Shall= requirement • Will= facts or declaration of purpose • Should = goal • Product Requirement • The requirement is in the form “product ABC shall XYZ.” A requirement must state “The product shall” (do, perform, provide, weigh, or other verb) followed by a description of what must be done. • The requirement uses consistent terminology to refer to the product and its lower level entities. • Complete with tolerances for qualitative/performance values (e.g., less than, greater than or equal to, plus or minus,3 sigma root sum squares). • Is the requirement free of implementation? (Requirements should state WHAT is needed, NOT HOW to provide it; i.e., state the problem not the solution. Ask, “Why do you need the requirement?” The answer may point to the real requirement.) • Free of descriptions of operations? (Is this a need the product must satisfy or an activity involving the product? Sentences like “The operator shall…” are almost always operational statements not requirements.)

29. How to Write a Good Requirements • Example Product Requirements • The system shall operate at a power level of… • The software shall acquire data from the… • The structure shall withstand loads of… • The hardware shall have a mass of…

30. Example RequirementsChecklist Categories Clarity Completeness Complexity Consistency Constraints Feasibility Functionality/Logic Interfaces Standards TBDs Testability Traceability Etc.

31. Capturing Requirements and the Requirements Database • At the time the requirements are written, it is important to capture the requirements statements along with the metadata associated with each requirement. • The metadata is the supporting information necessary to help clarify and link the requirements.

32. Systems Engineering Process

33. Systems Engineering Process

34. Requirements Management • Apply to the management of all stakeholder expectations, customer requirements, and technical product requirements down to the lowest level product component requirements • The Requirements Management Process is used to: • Manage the product requirements identified, baselined, and used in the definition of the WBS model products during system design; • Provide bidirectional traceability back to the top WBS model requirements; • Manage the changes to established requirement baselines over the life cycle of the system products.

35. Requirements Management Process

36. Requirements Management Process • Involves managing all changes to expectations and requirements baselines over the life of the product and maintaining bidirectional traceability between • stakeholder expectations, • customer requirements, • technical product requirements, • product component requirements, • design documents, • test plans and procedures.

37. Requirements Management Process • The successful management of requirements involves several key activities: • Establish a plan for executing requirements management. • Receive requirements from the system design processes and organize them in a hierarchical tree structure. • Establish bidirectional traceability between requirements. • Validate requirements against the stakeholder expectations, the mission objectives and constraints, the operational objectives, and the mission success criteria. • Define a verification method for each requirement. • Baseline requirements. • Evaluate all change requests to the requirements baseline over the life of the project and make changes if approved by change board. • Maintain consistency between the requirements, and the architecture/design and initiate corrective actions to eliminate inconsistencies.

38. References • NASA Reference Publication 1370, Training Manual for Elements of Interface Definition and Control • NASA Systems Engineering Handbook, NASA/SP-2007-6105, Rev1, 2007 • SYSTEMS ENGINEERING FUNDAMENTALS, SUPPLEMENTARY TEXT PREPARED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS FORT BELVOIR, VIRGINIA 22060-5565, January 2001 • IEEE Guide for Developing System Requirements Specifications, IEEE Std 1233, 1998 Edition • IEEE Recommended Practice forSoftware Requirements Specifications, IEEE Std 830-1998 • Space engineering Technical requirements specification, ECSS-E-ST-10-06C, ESA-ESTEC Requirements & Standards Division, 6 March 2009

39. Backup slides

40. Characteristics of a technical requirement • Performance • a. Each technical requirement shall be described in quantifiable terms. • b. If necessary to remove possible ambiguities of a given performance • requirement the method used to determine the required performance • shall be indicated in the requirement itself. • Justification • a. Each technical requirement should be justified. • b. The entity responsible of the technical requirement shall be identified. • c. The entity responsible of the specification shall define what part of the justification shall be included in the specification as informative material. • Configuration management and traceability, • a. Each technical requirement shall be under configuration management. • b. All technical requirements shall be backwards-traceable. • c. All technical requirements shall be forward-traceable. • A technical requirement is traceable when it is possible to trace the history, application, or location of a requirement by means of recorded identification. • Ambiguity • a. The technical requirements shall be unambiguous.

41. Characteristics of a technical requirement • Uniqueness • a. Each technical requirement shall be unique. • Identifiability • a. A technical requirement shall be identified in relation to the relevant function, product or system. • b. A unique identifier shall be assigned to each technical requirement. • c. The unique identifier should reflect the type of the technical requirement. • d. The unique identifier should reflect the life profile situation. • Singularity • a. Each technical requirement shall be separately stated.(not the combination of two or more technical requirements) • Completeness • a. A technical requirement shall be self-contained. (when is complete and does not require additional data or explanation to express the need). • Verification • a. A technical requirement shall be verifiable using one or more approved verification methods. • Tolerance • a. The tolerance shall be specified for each parameter/variable. ( range of values within which the conformity to the requirement is accepted).