Agree in real life this requirement would not be needed. Sarah's point was to use it as an example for appropriate range within the 7 examples so had to stretch things a little.

@@incoserwg891 It's toy examples, I understand, but I think there's a risk that inexperienced requirement authors look at such examples and try to emulate them. And to top it off, the example is incorrect (1 ... 24 instead of 0 .. 23). :-( I think there's a real need for good (and bad) examples of requirements, beyond the toy level...

We will be adding update videos as soon as we can. Also, if you are a member of INCOSE, you can visit the RWG iNet site for current information and status.

Wont it be solution oriented approach if we extract requirements from Architecture ? ( Interesting Perspective )

I see it as an iterative process.

Glad you found it useful. Having the ability to post these presentation is a great addition to the services the RWG provides to the SE community.

makzmakz Glad you enjoyed the presentation. You have the main idea in that 1) Interface requirements are functional/performance requirements and 2) the performance is the defined and agreed to definition of an interaction often contained in an ICD type of document. In this example the characteristics of the measurement parameter and the command. For data, command, and messages some organizations will have a separate data dictionary that defines the characteristics of each, others will include this information in an ICD. One thing about your example is that I don't think the accuracy and precision are part of the exchange of the measurement parameter, rather they are part of the act of obtaining the measurement in the first place. Something like: "The Payload shall measure tmpMsrmnt1 with an accuracy of of +/- 0.1 degC" and "The Payload shall measure tmpMsrmnt1 with a precision of +/- 0.05 degC." There would be other requirements concerning the sample rate and storage. From a single thought perspective and thinking ahead to system verification, I broke this into separate requirements. Another thing is the wordiness of the requirement - the less words the better while still being clear as too the intent while keeping the requirement a single thought as discussed above. As discussed in the INCOSE Guide to Writing Requirements (GtWR), including qualifying clauses is allowed and encouraged when appropriate to the level the requirement is being stated. These clauses also are an aid in planning ahead for how the system will be verified to meet the requirement as well as an aid when developing models of the system. In this case the command from the spacecraft is a trigger for the Payload to send the temperature measurement to the spacecraft. From a states and modes perspective, some organizations will include the state or mode as an attribute rather than as part of the requirement wording. This is helpful when wanting to list all the requirements that apply to a specific state or mode. This is discussed in the INCOSE RWG Needs and Requirements Manual (NRM) chapter on attributes. With these things in mind along with the assumption the state/mode is included as an attribute of the requirements rather than as part of the requirement statement text the following interface requirement could be stated. "The Payload shall send payload temperature measurement TmpMsrmnt1 defined in Spacecraft ICD 1234, Table 5.4 row 2 to the Spacecraft within 2 ms upon receipt of the spacecraft payload temperature request TmpMsmrntReq1 defined in Spacecraft ICD 1234, Table 5.4 row 10." Because the measurement and command are proper nouns I capitalized them.

Jay, For existing systems, you are correct - an ICD should have been developed and baselined. This ICD then contains the information needed by new systems to be developed in the future to be able to interact with the existing system. As such, the existing system is a constraint on any new system being developed in the future that will interact in some way with the existing system. In the example you refer to there is an existing spacecraft that a new payload or instrument is being integrated into. Thus this new system is constrained by the existing spacecraft buss. Therefore the new system must have interface requirements concerning each interaction and these must include a pointer to the existing systems ICD. If both the spacecraft and payload are being developed concurrently, then what you say is also correct. Each will have interface requirements as design inputs that address each identified interaction from the perspective of what the interaction involves and characteristics of the things involved in the interactions. This information is included in a preliminary ICD and is referred to within the interface requirements. As design inputs, these requirements provide the design team the knowledge they need to come up with a design the enables the interaction to take place. Because the design has not been completed and agreed to, other interface requirements that depend on the design include a TBD until the design is complete. Once complete, the design information is added to the ICD and the TBDs in the interface requirements are replaced with pointers to the ICD. These requirements must be stated to not only drive design, but also because the build systems must be verified to meet all the interface requirements. If you go back and listen to the presentation and subsequent discussion, you will see that what I just said was discussed. If you have more questions, I suggest you read the sections in the INCOSE RWG Needs and Requirements Manual in section 4, 6, and 14 that discuss interfaces and interface requirements.

The presentation file can be found at our website: www.incose.org/incose-member-resources/working-groups/process/requirements

@@incoserwg891 Thank you kindly. I love the resources and videos. If you're able to pass on feedback, could you have a systems engineer look at the whole website design? It's exceptionally difficult to find things, exceptionally difficult to buy things, even when you specifically know what you want to buy in advance. No obvious structure on where to click to buy a document. The user experience is unfamiliar even to an avid online shopper. I sometimes unexpectedly get redirected e.g. to a login page or a home page. There are documents which even when knowing the title, don't even seem show up on Google search. Plus the site feels 20 years out of date. The site seems to be a great anti-thesis to systems engineering practices. Also my company's purchasing department struggled to find a way to purchase something from the INCOSE website.